Введение в клиент-серверные технологии Веб. Протокол HTTP. Методы и структура протокола HTTP

1. Протокол HTTP. Введение

Сразу хочу уточнить одну маленькую вещь. Страшное слово протокол есть не что иное, как соглашение множества людей, просто в один прекрасный момент люди решили: "Давайте будем делать так, и тогда все будет в порядке". Бояться нечего, все просто до безобразия и это безобразие мы сейчас будем вскрывать. Итак, что же это такое протокол HTTP и с чем его едят?

1.1 Клиент и сервер

Чудес в мире, а тем более в мире программизма и интернета не бывает! Усвойте это как незыблемую истину. И, если программа не работает или работает не так как хочется, то, значит, скорее всего, она либо написана не правильно, либо содержит ошибки. Итак, как же все-таки браузер просит сервер прислать ему хоть что-нибудь? Да очень просто! Надо только немного расслабиться и начать получать удовольствие от процесса:-)

1.2. Пишем наш первый HTTP запрос

Если Вы думаете, что все слишком сложно, то Вы ошибаетесь. Человек так устроен, что просто не способен создавать что-то сложное, иначе он сам в этом запутается:-) Итак, есть браузер и есть Web-сервер. Инициатором обмена данными всегда выступает браузер. Web-сервер никому, никогда просто так ничего не пошлет, чтобы он что-нибудь отправил браузеру - надо, чтобы браузер об этом попросил. Простейший HTTP запрос моет выглядеть, например, так:

GET http : //www.php.net/ HTTP/1.0rnrn

* GET (В переводе с английского означает "получить") - тип запроса, тип запроса может быть разным, например POST, HEAD, PUT, DELETE (часть из них мы рассмотрим ниже).
* http://www.php.net/ - URI (адрес) от которого мы хотим получить хоть какую-нибудь информацию (естественно мы надеемся подучить HTML страницу).
* HTTP/1.0 - тип и версия протокола, который мы будем использовать в процессе общения с сервером.
* rn - конец строки, который необходимо повторить два раза, зачем, станет понятно немного позднее.

Вы можете выполнить данный запрос очень просто. Запустите программу telnet.exe, введите в качестве хоста www.php.net, укажите порт 80, и просто наберите данный запрос, нажав два раза Enter в качестве rnrn. В ответ вы получите HTML код главной страницы сайта www.php.net.

1.3 Структура запроса

Рассмотрим, из чего состоит HTTP запрос. Все достаточно просто. Начнем с того, что HTTP запрос - это вполне осмысленный текст. Из чего же он состоит в общем случае? Будем рассматривать протокол HTTP 1.0. Итак :

Request - Line [ General - Header | Request - Header | Entity - Header ] rn [ Entity - Body ]

* Request-Line - строка запроса
*

Формат : "Method Request-URI HTTP-Versionrn"
* Method - метод , которым будет обрабатываться ресурс Request-URI, может быть GET, POST, PUT, DELETE или HEAD.
* Request-URI - относительная или абсолютная ссылка на страницу с набором параметров, например, /index.html или http://www.myhost.ru/index.html или /index.html?a=1&b=qq. В последнем случае серверу будет передан запрос с набором переменных a и b с соответствующими значениями, а знак "&" - амперсант служит разделителем между параметрами.
* HTTP-Version - версия HTTP протокола, в нашем случае "HTTP/1.0".

Нам крайне интересны методы обработки GET и POST. Методом GET можно просто передать параметры в скрипт, а методом POST можно эмулировать submit формы.

Для метода GET, Request-URI может выглядеть, например, так: "/index.html?param1=1¶m2=2".

* General-Header - главная часть заголовка.
Формат:
Может иметь только два параметра: Date или Pragma. Date - дата по Гринвичу в формате "День недели, Число Месяц Год ЧЧ:ММ:СС GMT", например, "Tue, 15 Nov 1994 08:12:31 GMT" - дата создания запроса. Pragma может иметь одно значение no-cache, которое запрещает кэширование страницы.

* Request-Header - часть заголовка , описывающая запрос .

Request-Header может иметь следующие параметры : Allow, Authorization, From, If-Modified-Since, Referer, User-Agent.
В данной главе мы не будем рассматривать параметр Autorization, так как он используется для доступа к закрытым ресурсам, что требуется не так уж часто. Вы можете самостоятельно изучить формирование заголовка для авторизованного доступа на сайте www.w3c.org.

* Allow - задает допустимые методы обработки.
Формат: "Allow: GET | HEADn".
Параметр игнорируется при указании метода обработки POST в Request-Line. Задает допустимые методы обработки запроса. Прокси сервера не модифицируют параметр Allow и он в неизменном виде доходит до сервера.

* From - e-mail адрес, пославшего запрос.
Формат: "From: adderssrn".
Например, "From: [email protected]".

* If-Modified-Since - указывает, что запрос не модифицировался с такого-то времени.
Формат: "If-Modified-Since: datern"
Используется только для метода обработки GET. Дата указывается по Гринвичу в таком же формате, как и для параметра Date в General-Header.

* Referrer - абсолютная ссылка на страницу, с которой произошла инициация запроса, т. е. ссылка на страницу, с которой пользователь перешел на нашу.
Формат: "Referrer: urln".
Пример: "Referrer: www.host.ru/index.htmln".
* User-Agent - тип браузера.
Например: "User-Agent: Mozilla/4.0n"

* Entity-Header - часть заголовка, описывающая данные Entity-Body.
В данной части запроса задаются параметры, которые описывают тело страницы. Entity-Header может содержать следующие параметры: Allow, Content-Encoding, Content-Length, Content-Type, Expires, Last-Modified, extension-header.

* Allow - параметр аналогичный Allow из General-Header.

* Content-Encoding - тип кодирования данных Entity-Body.
Формат: "Сontent-Encoding: x-gzip | x-compress | другой типn".
Пример: "Сontent-Encoding: x-gzipn". Символ "|" означает слово "или", то есть то или то или то и.т.д.
Другой тип может указывать на способ кодирования данных, например, для метода POST: "Сontent-Encoding: application/x-www-form-urlencodedn".

* Content-Length - количество байт, пересылаемых в Entity-Body. Значение Content-Length имеет совсем другой смысл для данных, пересылаемых в формате MIME, где он выступает как параметр описания части данных - "external/entity-body". Допустимыми являются целые числа от нуля и больше.
Пример: "Content-Length: 26457n".

* Content-Type - тип передаваемых данных.
Например: "Content-Type: text/htmln".

* Expires - Время, когда страница должна быть удалена из кэша браузера.
Формат: "Expires: daten". Формат даты алогичен формату даты для параметра Date из General-Header.

* Last-Modified - время последнего изменения пересылаемых данных.
Формат: "Last-Modified: daten". Формат даты алогичен формату даты для параметра Date из General-Header.

* Extention-header - часть заголовка, которая может предназначаться, например, для обработки браузером, или другой программой, которая принимает документ. В данной части можно описывать свои параметры в формате "ParameterName: parametervaluen". Данные параметры будут игнорироваться, если программа-клиент не знает, как их обработать.
Например: "Cookie: r=1rn" - устанавливает всем известные печеньки для страницы.

А теперь после таких страшных слов давайте попробуем немного успокоиться и понять, что же нам надо? Понимать мы естественно будем на примерах.

Давайте представим, что нам надо получить страницу с сайта, передав Cookies (Печеньки), иначе нас просто пошлют как незванных гостей, и более того, известно, что на данную страницу пускают только после того, как Вы побывали на главной странице сайта.

2 Метод GET

Напишем наш запрос.

GET http :
Host : www . site . rurn

Cookie : income = 1rn
rn

Данный запрос говорит нам о том, что мы хотим получить содержимое страницы по адресу http://www.site.ru/news.html, использую метод GET. Поле Host говорит о том, что данная страница находится на сервере www.site.ru, поле Referer говорит о том, что за новостями мы пришли с главной страницы сайта, а поле Cookie говорит о том, что нам была присвоена такая-то кука. Почему так важны поля Host, Referer и Сookie? Потому что нормальные программисты при создании динамических сайтов проверяют данные поля, которые появляются в скриптах (РНР в том числе) в виде переменных. Для чего это надо? Для того, например, чтобы сайт не грабили, т.е. не натравливали на него программу для автоматического скачивания, или для того, чтобы зашедший на сайт человек всегда попадал бы на него только с главной страницы и.т.д.

Теперь давайте представим, что нам надо заполнить поля формы на странице и отправить запрос из формы, пусть в данной форме будет два поля: login и password (логин и пароль),- и, мы естественно знаем логин и пароль.

GET http : //www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0rn
Host : www . site . rurn
Referer : http : //www.site.ru/index.htmlrn
Cookie : income = 1rn
rn

Логин у нас "Petya Vasechkin" Почему же мы должны писать Petya%20Vasechkin? Это из=за того, что специальные символы могут быть распознаны сервером, как признаки наличия нового параметра или конца запроса и.т.д. Поэтому существует алгоритм кодирования имен параметров и их значений, во избежание оштбочных ситуаций в запросе. Полное описание данного алгоритма можно найти здесь, а в PHP есть функции rawurlencode и rawurldecode для кодирования и декодирования соответственно. Хочу отметеить, что декодирование РНР делает сам, если в запросе были переданы закодированные параметры. На этом я закону первую главу знакомства c протоколом HTTP. В следуючей главе мы рассмотрим построение запросов типа POST (в переводе с английского - "отправить"), что будет гораздо интереснее, т.к. именно данный тип запросов используется при отправке данных из HTML форм.

3. Метод POST.

В случае HTTP запроса типа POST существует два варианта передачи полей из HTML форм, а именно, используя алгоритм application/x-www-form-urlencoded и multipart/form-data. Различия между данными алгоритмами весьма существенные. Дело в том, что алгоритм первого типа создавался давным-давно, когда в языке HTML еще не предусматривали возможность передачи файлов через HTML формы. Итак, давайте рассмотрим эти алгоритмы на примерах.

3.1 Content-Type: application/x-www-form-urlencoded.

Пишем запрос, аналогичный нашему запросу GET для передачи логина и пароля, который был рассмотрен в предыдущей главе:

POST http : //www.site.ru/news.html HTTP/1.0rn
Host : www . site . rurn
Referer : http : //www.site.ru/index.htmlrn
Cookie : income = 1rn
Content - Type : application / x - www - form - urlencodedrn
Content - Length : 35rn
rn

Здесь мы видим пример использования Content-Type и Content-Length полей заголовка. Content-Length говорит, сколько байт будет занимать область данных, которая отделяется от заголовка еще одним переводом строки rn. А вот параметры, которые раньше для запроса GET помещались в Request-URI, теперь находятся в Entity-Body. Видно, что они формируются точно также, просто надо написать их после заголовка. Хочу отметить еще один важный момент, ничто не мешает, одновременно с набором параметров в Entity-Body, помещать параметры с другими именами в Request-URI, например:

POST http : //www.site.ru/news.html?type=user HTTP/1.0rn
.....
rn
login = Petya % 20Vasechkin & password = qq

3.2 Content-Type: multipart/form-data

Как только интернет мир понял, что неплохо бы было через формы отсылать еще и файлы, так W3C консорциум взялся за доработку формата POST запроса. К тому времени уже достаточно широко применялся формат MIME (Multipurpose Internet Mail Extensions - многоцелевые расширения протокола для формирования Mail сообщений), поэтому, чтобы не изобретать велосипед заново, решили использовать часть данного формата формирования сообщений для создания POST запросов в протоколе HTTP.

Каковы же основные отличия этого формата от типа application/x-www-form-urlencoded?

Главное отличие в том, что Entity-Body теперь можно поделить на разделы, которые разделяются границами (boundary). Что самое интересное - каждый раздел может иметь свой собственный заголовок для описания данных, которые в нем хранятся, т.е. в одном запросе можно передавать данные различных типов (как в Mail письме Вы одновременно с текстом можете передавать файлы).

Итак, приступим. Рассмотрим опять все тот же пример с передачей логина и пароля, но теперь в новом формате.

POST http : //www.site.ru/news.html HTTP/1.0rn
Host : www . site . rurn
Referer : http : //www.site.ru/index.htmlrn
Cookie : income = 1rn

Content - Length : 209rn
rn
-- 1BEF0A57BE110FD467Arn
Content - Disposition : form - data ; name = "login" rn
rn
Petya Vasechkinrn
-- 1BEF0A57BE110FD467Arn
Content - Disposition : form - data ; name = "password" rn
rn
qqrn
-- 1BEF0A57BE110FD467A -- rn

Теперь давайте разбираться в том что написано. :-) Я специально выделил некоторые символы rn жирным, чтобы они не сливались с данными. Присмотревшись внимательно можно заметить поле boundary после Content-Type. Это поле задает разделитель разделов - границу. В качестве границы может быть использована строка, состоящая из латинских букв и цифр, а так же из еще некоторых символов (к сожалению, не помню каких еще). В теле запроса в начало границы добавляется "--", а заканчивается запрос - границей, к которой символы "--" добавляются еще и в конец. В нашем запросе два раздела, первый описывает поле login, а второй поле password. Content-Disposition (тип данных в разделе) говорит, что это будут данные из формы, а в поле name задается имя поля. На этом заголовок раздела заканчивается и далее следует область данных раздела, в котором помещается значение поля (кодировать значение не требуется!).

Хочу обратить Ваше внимание та то, что в заголовках разделов не надо использовать Content-Length, а вот в заголовке запроса надо и его значение является размером всего Entity-Body, стоящего после второго rn, следующего за Content-Length: 209rn. Т.е. Entity-Body отделяется от заголовка дополнительным переводом строки (что можно заметить и в разделах).

А теперь давайте напишем запрос для передачи файла.

POST http : //www.site.ru/postnews.html HTTP/1.0rn
Host : www . site . rurn
Referer : http : //www.site.ru/news.htmlrn
Cookie : income = 1rn
Content - Type : multipart / form - data ; boundary = 1BEF0A57BE110FD467Arn
Content - Length : 491rn
rn
-- 1BEF0A57BE110FD467Arn
Content - Disposition : form - data ; name = "news_header" rn
rn
Пример новостиrn
-- 1BEF0A57BE110FD467Arn
Content - Disposition : form - data ; name = "news_file" ; filename = "news.txt" rn
Content - Type : application / octet - streamrn
Content - Transfer - Encoding : binaryrn
rn
А вот такая новость , которая лежит в файле news . txtrn
-- 1BEF0A57BE110FD467A -- rn

В данном примере в первом разделе пересылается заголовок новости, а во втором разделе пересылается файл news.txt. Внимательный да увидит поля filename и Content-Type во втором разделе. Поле filename задает имя пересылаемого файла, а поле Content-Type - тип данного файла. Application/octet-stream говорит о том, что это стандартный поток данных, а Content-Transfer-Encoding: binary говорит на о том, что это бинарные данные, ничем не закодированные.

Очень важный момент. Большинство CGI скриптов написано умными людьми, поэтому они любят проверять тип пришедшего файла, который стоит в Content-Type. Зачем? Чаще всего закачка файлов на сайтах используется для получения картинок от посетителя. Так вот, браузер сам пытается определить что за файл посетитель хочет отправить и вставляет соответствующий Content-Type в запрос. Скрипт его проверяет при получении, и, например, если это не gif или не jpeg игнорирует данный файл. Поэтому при "ручном" формировании запроса позаботьтесь о значении Content-Type, чтобы оно было наиболее близким к формату передаваемого файла.

Image/gif для gif
image/jpeg для jpeg
image/png для png
image/tiff для tiff (что используется крайне редко, уж больно емкий формат)

В нашем примере формируется запрос, в котором передается текстовый файл. Точно так же формируется запрос для передачи бинарного файла.

4. Постскриптум.

Думаю, что о передаче запросов на сервер не стоит рассказывать подробно. Это уже дело чисто РНР техники:-). Достаточно внимательно прочитать раздел о функциях работы с сокетами, или о функциях модуля CURL в официальной документации РНР.

Из выше сказанного, надеюсь теперь понятно, почему вопрос: "Как мне сформировать POST запрос, используя функцию header?" - бессмысленен. Функция header(string) добавляет запись только в заголовок запроса, но никак не в тело запроса.

Назад

HTTP запрос, или сообщение состоит из трех частей: строки запроса, и тела HTTP сообщения.

Строка запроса , или стартовая строка: в запросе к серверу — строка, которая содержит тип запроса (метод), URI запрашиваемой страницы, и версия (например HTTP/1.1). В ответе от сервера эта строка содержит версию HTTP протокола, и код ответа. Код ответа представляет собой целое число из трех цифр. За ним обычно следует отделённая пробелом поясняющая фраза, поясняющая код, например: 200 OK, или 404 Not Found.

Методы (типы) HTTP запроса : GET, POST, PUT, PATCH, HEAD, DELETE, TRACE. Чаще всего в HTTP запросе используются методы GET, или POST: GET — используется для запроса содержимого web-страницы по указанному URI. URI — это адрес страницы без указания , например: /internet/chto-takoe-http-zapros-soobshhenie/ вместо сайт/internet/chto-takoe-http-zapros-soobshhenie/. Браузер может передавать параметры в GET в URI после символа « ? »: GET /index.php?param1=value1¶m2=value2. Кроме обычного метода GET, различают ещё условный GET и частичный GET. Условные запросы GET содержат заголовки If-Modified-Since , If-Match , If-Range и подобные.

POST — используется для отправки информации, на . При отправке данных методом POST, они указываются в теле HTTP сообщения, а не в строке ввода адреса в браузере, как это делается при передаче данных методом GET. Например, при отправке комментария через форму, которая расположена под статьей, информация на сервер передается именно методом POST. Так же с помощью метода POST загружают файлы на сервер.

— это часть запроса, в котором содержатся различные параметры, которые используются для правильного построения web-страницы.

Тело HTTP сообщения — содержит полученные от сервера данные, например сформированную web-страницу в виде HTML кода, либо ресурс, например картинку.

Пример HTTP сообщений:

HTTP запрос к серверу:

GET /internet/chto-takoe-http-zapros-soobshhenie/ HTTP/1..9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2150.0 Accept-Encoding: gzip, deflate, sdch Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4 Cookie: wp-settings-1=hidetb%3D; wp-settings-time-1=1424958215; wordpress_test_cookie=WP+Cookie;

Ответ от сервера:

HTTP/1.1 200 OK - стартовая строка ответа : Server: nginx/1.6.2 Date: Sun, 19 Apr 2015 00:22:50 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 9431 Connection: keep-alive Keep-Alive: timeout=30 X-Powered-By: PHP/5.5.22 Expires: Wed, 11 Jan 1984 05:00:00 GMT Cache-Control: no-cache, must-revalidate, max-age=0 Pragma: no-cache Vary: Accept-Encoding Content-Encoding: gzip Далее следует тело ответа (страница в HTML).

HTTP - это протокол передачи гипертекста между распределёнными системами. По сути, http является фундаментальным элементом современного Web-а. Как уважающие себя веб разработчики, мы должны знать о нём как можно больше.

Давайте взглянем на этот протокол через призму нашей профессии. В первой части пройдёмся по основам, посмотрим на запросы/ответы. В следующей статье разберём уже более детальные фишки, такие как кэширование, обработка подключения и аутентификация.

Также в этой статье я буду, в основном, ссылаться на стандарт RFC 2616 : Hypertext Transfer Protocol -- HTTP/1.1.

Основы HTTP

HTTP обеспечивает общение между множеством хостов и клиентов, а также поддерживает целый ряд сетевых настроек.

В основном, для общения используется TCP/IP, но это не единственный возможный вариант. По умолчанию, TCP/IP использует порт 80, но можно заюзать и другие.

Общение между хостом и клиентом происходит в два этапа: запрос и ответ. Клиент формирует HTTP запрос, в ответ на который сервер даёт ответ (сообщение). Чуть позже, мы более подробно рассмотрим эту схему работы.

Текущая версия протокола HTTP - 1.1, в которой были введены некоторые новые фишки. На мой взгляд, самые важные из них это: поддержка постоянно открытого соединения, новый механизм передачи данных chunked transfer encoding, новые заголовки для кэширования. Что-то из этого мы рассмотрим во второй части данной статьи.

URL

Сердцевиной веб-общения является запрос, который отправляется через Единый указатель ресурсов (URL). Я уверен, что вы уже знаете, что такое URL адрес, однако для полноты картины, решил всё-таки сказать пару слов. Структура URL очень проста и состоит из следующих компонентов:

Протокол может быть как http для обычных соединений, так и https для более безопасного обмена данными. Порт по умолчанию - 80. Далее следует путь к ресурсу на сервере и цепочка параметров.

Методы

С помощью URL, мы определяем точное название хоста, с которым хотим общаться, однако какое действие нам нужно совершить, можно сообщить только с помощью HTTP метода. Конечно же существует несколько видов действий, которые мы можем совершить. В HTTP реализованы самые нужные, подходящие под нужды большинства приложений.

Существующие методы:

GET : получить доступ к существующему ресурсу. В URL перечислена вся необходимая информация, чтобы сервер смог найти и вернуть в качестве ответа искомый ресурс.

POST : используется для создания нового ресурса. POST запрос обычно содержит в себе всю нужную информацию для создания нового ресурса.

PUT : обновить текущий ресурс. PUT запрос содержит обновляемые данные.

DELETE : служит для удаления существующего ресурса.

Данные методы самые популярные и чаще всего используются различными инструментами и фрэймворками. В некоторых случаях, PUT и DELETE запросы отправляются посредством отправки POST, в содержании которого указано действие, которое нужно совершить с ресурсом: создать, обновить или удалить.

Также HTTP поддерживает и другие методы:

HEAD : аналогичен GET. Разница в том, что при данном виде запроса не передаётся сообщение. Сервер получает только заголовки. Используется, к примеру, для того чтобы определить, был ли изменён ресурс.

TRACE : во время передачи запрос проходит через множество точек доступа и прокси серверов, каждый из которых вносит свою информацию: IP, DNS. С помощью данного метода, можно увидеть всю промежуточную информацию.

OPTIONS : используется для определения возможностей сервера, его параметров и конфигурации для конкретного ресурса.

Коды состояния

В ответ на запрос от клиента, сервер отправляет ответ, который содержит, в том числе, и код состояния. Данный код несёт в себе особый смысл для того, чтобы клиент мог отчётливей понять, как интерпретировать ответ:

1xx: Информационные сообщения

Набор этих кодов был введён в HTTP/1.1. Сервер может отправить запрос вида: Expect: 100-continue, что означает, что клиент ещё отправляет оставшуюся часть запроса. Клиенты, работающие с HTTP/1.0 игнорируют данные заголовки.

2xx: Сообщения об успехе

Если клиент получил код из серии 2xx, то запрос ушёл успешно. Самый распространённый вариант - это 200 OK. При GET запросе, сервер отправляет ответ в теле сообщения. Также существуют и другие возможные ответы:

202 Accepted : запрос принят, но может не содержать ресурс в ответе. Это полезно для асинхронных запросов на стороне сервера. Сервер определяет, отправить ресурс или нет.
204 No Content : в теле ответа нет сообщения.
205 Reset Content : указание серверу о сбросе представления документа.
206 Partial Content : ответ содержит только часть контента. В дополнительных заголовках определяется общая длина контента и другая инфа.

3xx: Перенаправление

Своеобразное сообщение клиенту о необходимости совершить ещё одно действие. Самый распространённый вариант применения: перенаправить клиент на другой адрес.

301 Moved Permanently : ресурс теперь можно найти по другому URL адресу.
303 See Other : ресурс временно можно найти по другому URL адресу. Заголовок Location содержит временный URL.
304 Not Modified : сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности - Enttity Tag);

4xx: Клиентские ошибки

Данный класс сообщений используется сервером, если он решил, что запрос был отправлен с ошибкой. Наиболее распространённый код: 404 Not Found. Это означает, что ресурс не найден на сервере. Другие возможные коды:

400 Bad Request : вопрос был сформирован неверно.
401 Unauthorized : для совершения запроса нужна аутентификация. Информация передаётся через заголовок Authorization.
403 Forbidden : сервер не открыл доступ к ресурсу.
405 Method Not Allowed : неверный HTTP метод был задействован для того, чтобы получить доступ к ресурсу.
409 Conflict : сервер не может до конца обработать запрос, т.к. пытается изменить более новую версию ресурса. Это часто происходит при PUT запросах.

5xx: Ошибки сервера

Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:

501 Not Implemented : сервер не поддерживает запрашиваемую функциональность.
503 Service Unavailable : это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

Форматы сообщений запроса/ответа

На следующем изображении вы можете увидеть схематично оформленный процесс отправки запроса клиентом, обработка и отправка ответа сервером.

Давайте посмотрим на структуру передаваемого сообщения через HTTP:

Message = *() CRLF [] = Request-Line | Status-Line = Field-Name ":" Field-Value

Между заголовком и телом сообщения должна обязательно присутствовать пустая строка. Заголовков может быть несколько:

Тело ответа может содержать полную информацию или её часть, если активирована соответствующая возможность (Transfer-Encoding: chunked). HTTP/1.1 также поддерживает заголовок Transfer-Encoding.

Общие заголовки

Вот несколько видов заголовков, которые используются как в запросах, так и в ответах:

Что-то мы уже рассмотрели в этой статье, что-то подробней затронем во второй части.

Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.

Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache - это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.

Заголовок Date используется для хранения даты и времени запроса/ответа.

Заголовок Upgrade используется для изменения протокола.

Transfer-Encoding предназначается для разделения ответа на несколько фрагментов с помощью Transfer-Encoding: chunked. Это нововведение версии HTTP/1.1.

Заголовки сущностей

В заголовках сущностей передаётся мета-информация контента:

Все заголовки с префиксом Content- предоставляют информацию о структуре, кодировке и размере тела сообщения.

Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.

С помощью данных заголовков, можно задать нужную для ваших задач информацию.

Формат запроса

Запрос выглядит примерно так:

SP - это разделитель между токенами. Версия HTTP указывается в HTTP-Version. Реальный запрос выглядит так:

GET /articles/http-basics HTTP/1.1 Host: www.articles.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Список возможных заголовков запроса:

В заголовке Accept определяется поддерживаемые mime типы, язык, кодировку символов. Заголовки From, Host, Referer и User-Agent содержат информацию о клиенте. Префиксы If- предназначены для создания условий. Если условие не прошло, то возникнет ошибка 304 Not Modified.

Формат ответа

Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

HTTP версия
Код статуса
Сообщение статуса, понятное для человека

Обычный статус выглядит примерно так:

HTTP/1.1 200 OK

Заголовки ответа могут быть следующими:

Age время в секундах, когда сообщение было создано на сервере.
ETag MD5 сущности для проверки изменений и модификаций ответа.
Location используется для перенаправления и содержит новый URL адрес.
Server определяет сервер, где было сформирован ответ.

Думаю, на сегодня теории достаточно. Теперь давайте взглянем на инструменты, которыми мы можем пользоваться для мониторинга HTTP сообщений.

Инструменты для определения HTTP трафика

Существует множество инструментов для мониторинга HTTP трафика. Вот несколько из них:

Наиболее часто используемый - это Chrome Developers Tools:

Если говорить об отладчике, можно воспользоваться Fiddler :

Для отслеживания HTTP трафика вам потребуется curl, tcpdump и tshark.

Библиотеки для работы с HTTP - jQuery AJAX

Поскольку jQuery очень популярен, в нём также есть инструментарий для обработки HTTP ответов при AJAX запросах. Информацию о jQuery.ajax(settings) можете найти на официальном сайте .

Передав объект настроек (settings), а также воспользовавшись функцией обратного вызова beforeSend, мы можем задать заголовки запроса, с помощью метода setRequestHeader().

$.ajax({ url: "http://www.articles.com/latest", type: "GET", beforeSend: function (jqXHR) { jqXHR.setRequestHeader("Accepts-Language", "en-US,en"); } });

Если хотите обработать статус запроса, то это можно сделать так:

$.ajax({ statusCode: { 404: function() { alert("page not found"); } } });

Итог

Вот такой вот он, тур по основам протокола HTTP. Во второй части будет ещё больше интересных фактов и примеров.

Этот пост - ответ на вопрос, заданный в к одной из моих статей.

В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.

HTTP

Итак, что же представляет из себя один из основных протоколов интернета? Педантов отправлю к RFC2616 , а остальным расскажу по-человечески:)

Этот протокол описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.

Стартовые строки для запроса и ответа имеют различный формат - нам интересна только стартовая строка запроса, которая выглядит так:

METHOD URI HTTP/VERSION ,

Где METHOD - это как раз метод HTTP-запроса, URI - идентификатор ресурса, VERSION - версия протокола (на данный момент актуальна версия 1.1).

Заголовки - это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.

Тело сообщения - это, собственно, передаваемые данные. В ответе передаваемыми данными, как правило, является html-страница, которую запросил браузер, а в запросе, например, в теле сообщения передается содержимое файлов, загружаемых на сервер. Но как правило, тело сообщения в запросе вообще отсутствует.

Пример HTTP-взаимодействия

Рассмотрим пример.

Запрос:
GET /index.php HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accept: text/html Connection: close
Первая строка - это строка запроса, остальные - заголовки; тело сообщения отсутствует

Ответ:
HTTP/1.0 200 OK Server: nginx/0.6.31 Content-Language: ru Content-Type: text/html; charset=utf-8 Content-Length: 1234 Connection: close ... САМА HTML-СТРАНИЦА...

Ресурсы и методы

Вернемся к стартовой строке запроса и вспомним, что в ней присутствует такой параметр, как URI. Это расшифровывается, как Uniform Resource Identifier - единообразный идентификатор ресурса. Ресурс - это, как правило, файл на сервере (пример URI в данном случае "/styles.css"), но вообще ресурсом может являться и какой-либо абстрактный объект ("/blogs/webdev/" - указывает на блок «Веб-разработка», а не на конкретный файл).

Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно - получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».

Для разграничения действий с ресурсами на уровне HTTP-методов и были придуманы следующие варианты:

GET - получение ресурса
POST - создание ресурса
PUT - обновление ресурса
DELETE - удаление ресурса

Обратите внимание на тот факт, что спецификация HTTP не обязывает сервер понимать все методы (которых на самом деле гораздо больше, чем 4) - обязателен только GET, а также не указывает серверу, что он должен делать при получении запроса с тем или иным методом. А это значит, что сервер в ответ на запрос DELETE /index.php HTTP/1.1 не обязан удалять страницу index.php на сервере, так же как на запрос GET /index.php HTTP/1.1 не обязан возвращать вам страницу index.php, он может ее удалять, например:)

В игру вступает REST

REST (REpresentational State Transfer) - это термин был введен в 2000-м году Роем Филдингом (Roy Fielding) - одним из разработчиков протокола HTTP - в качестве названия группы принципов построения веб-приложений. Вообще REST охватывает более широкую область, нежели HTTP - его можно применять и в других сетях с другими протоколами. REST описывает принципы взаимодействия клиента и сервера, основанные на понятиях «ресурса» и «глагола» (можно понимать их как подлежащее и сказуемое). В случае HTTP ресурс определяется своим URI, а глагол - это HTTP-метод.

REST предлагает отказаться от использования одинаковых URI для разных ресурсов (то есть адреса двух разных статей вроде /index.php?article_id=10 и /index.php?article_id=20 - это не REST-way) и использовать разные HTTP-методы для разных действий. То есть веб-приложение, написанное с использованием REST подхода будет удалять ресурс при обращении к нему с HTTP-методом DELETE (разумеется, это не значит, что надо давать возможность удалить всё и вся, но любой запрос на удаление в приложении должен использовать HTTP-метод DELETE).

REST дает программистам возможность писать стандартизованные и чуть более красивые веб-приложения, чем раньше. Используя REST, URI для добавления нового юзера будет не /user.php?action=create (метод GET/POST), а просто /user.php (метод строго POST).

В итоге, совместив имеющуюся спецификацию HTTP и REST-подход наконец-то обретают смысл различные HTTP-методы. GET - возвращает ресурс, POST - создает новый, PUT - обновляет существующий, DELETE - удаляет.

Проблемы?

Да, есть небольшая проблема с применением REST на практике. Проблема эта называется HTML.

PUT/DELETE запросы можно отправлять посредством XMLHttpRequest, посредством обращения к серверу «вручную» (скажем, через curl или даже через telnet), но нельзя сделать HTML-форму, отправляющую полноценный PUT/DELETE-запрос.

Дело в том, спецификация HTML не позволяет создавать формы, отправляющие данные иначе, чем через GET или POST. Поэтому для нормальной работы с другими методами приходится имитировать их искусственно. Например, в Rack (механизм, на базе которого Ruby взаимодействует с веб-сервером; с применением Rack сделаны Rails, Merb и другие Ruby-фреймворки) в форму можно добавить hidden-поле с именем "_method", а в качестве значения указать название метода (например, «PUT») - в этом случае будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.

С помощью заголовков http происходит обмен служебными сведениями между клиентом и сервером. Эта информация остается невидимой для пользователей, но без нее невозможна правильная работа браузера. Для обычных пользователей сведения об этом и о задачах http заголовков покажутся довольно сложными, но на самом деле они не содержат трудных формулировок. Это то, с чем сталкивается веб-пользователь ежедневно.

заголовки?

«Протокол передачи гипертекста» - именно так переводится Благодаря его существованию, возможна связь «клиент-сервер». Если объяснить простыми словами, пользователь браузера посылает запрос, инициируя соединение с сервером. Последний, по умолчанию, ждет запрос от клиента, обрабатывает его и посылает обратно итоговую информацию или ответ. В поисковой строке пользователь «вбивает» адрес сайта, который начинается с http:// и получает результат в виде открывшейся страницы.

Когда печатается адрес сайта в соответствующей строке, браузер находит требующийся сервер с помощью DNS. Сервер распознает http заголовок (один или несколько), который посылает ему клиент, а затем выдает требуемый header. Набор обязательных состоит из уже существующих заголовков и не найденных.

В общем, http заголовки достаточно эффективные. Их не видно в HTML-кодировании, они отправляются перед запрашиваемыми сведениями. Многие заголовки автоматически высылаются сервером. Для того чтобы его отослать на языке PHP, следует воспользоваться функцией header.

Взаимодействие браузера и сайта

Схема взаимодействия браузера и сайта достаточно простая. Так, http заголовок начинает строку запроса, который далее посылается серверу. В ответ приходит нужная клиенту информация. Между прочим, http протокол уже семнадцать лет - самый используемый в Интернете. Он простой, надежный, работает быстро и гибко. Главная задача http - запрос сведений с web-сервера. Клиентом является браузер, а сервером - ligthttp, apache, nginx. Если соединение между ними произошло успешно, сервер в ответ на запрос получает нужные сведения. Информация http содержит текстовые, звуковые файлы, видео.

Протокол может быть транспортом для других. Запрос клиента состоит из трех частей:

стартовой строки (тип сообщения);
заголовков (параметры сообщения);
тела информации (сообщение, которое отделяется пустой строчкой).

Стартовая строка - обязательный элемент запроса поля заголовков http. Структура запроса пользователя состоит из трех основных частей:

Метод. С его помощью указывается тип запроса.
Путь (path). Это строка URL, которая следует за доменом.
Используемый протокол. Он состоит из версии protocol и http.

Современные браузеры используют версию 1.1. Далее следуют заголовки в формате "Имя: значение".

HTTP-кэширование

Суть в том, что кэширование обеспечивает хранение HTML-страниц, других файлов в кэше (место в операционной памяти, на жестком диске компьютера). Это нужно для того чтобы ускорить к ним повторный доступ и сэкономить трафик.

Кэш имеет браузер клиента, промежуточный шлюз и прокси-сервер. Перед тем как отправить сообщение по URL, браузер проверит наличие объекта в кэше. Если объекта нет, запрос передается следующему серверу, где проверяется кэширование http заголовков на сервере nginx. Шлюзы и прокси используются разными пользователями, поэтому кэш является разделяемым.

HTTP-кэширование способно не только существенно ускорить работу сайта, но и предоставить старую версию страницы. С помощью происходит отправка заголовков на отклик. При этом не может быть кэширована информация, запрошенная по протоколу HTTPS.

Описание http заголовков

Одними из самых главных механизмов кеша считаются http заголовки expires. Эти заголовки сообщают о сроке годности предоставленной в отклике информации. В них указывается время и дата, когда кэш будет считаться устаревшим. Например, такой заголовок выглядит следующим образом: Expires: Wen, 30 Nov 2016 13:45:00 GMT. Данная структура используется почти везде, в том числе для кэширования страниц и картинок. Если пользователь выберет старую дату, сведения не будут кэшироваться.

Заголовки http proxy относятся к категории header link. Они не кэшируются по умолчанию. Чтобы кэш работал правильно, каждый URL должен соответствовать одному варианту содержимого. Если страница действует на двух языках, каждая версия должна иметь собственный URL. Заголовок vary сообщает кэшу названия заголовков запроса. К примеру, если отображение запроса зависит от браузера, серверу необходимо также отправлять заголовок. Таким образом, в кэше сохраняются разные варианты запросов и типы документов. TTP заголовок accept необходим для того чтобы составлять списки допустимых форматов используемого ресурса, с ним достаточно легко работать, так как он отсеивает ненужные.

Всего существует четыре группы заголовков, которые передают служебную информацию. Это основные заголовки - они содержатся в любом сообщении сервера и клиента, запроса и ответа, а также сущности. Последние описывают содержание любого сообщения от клиента и сервера.

HTTP заголовок authorization считается дополнительным. Когда web-страница спрашивает у клиента авторизацию, браузер отображает специальное окно с полями для ввода логина и пароля. После того как пользователь введет свои данные, браузер передает запрос http. Он содержит заголовок «авторизация».

Как увидеть заголовки?

Чтобы увидеть http заголовок, необходимо установить плагины для браузера, например, firefox:

Firebug. Просмотреть заголовки можно во вкладке net (сеть), где выбрать all (все). Этот плагин обладает функциями, которые будут полезны веб-разработчику.
Live http headers. Простой плагин, предназначенный для просмотров http заголовков. С его помощью вручную можно сгенерировать запрос.
Пользователи Ghrome легко увидят заголовки, если нажмут кнопку настроек, выберут инструменты разработчика (net works).

Когда плагины будут установлены, запустите их и браузера.

Методы запросов

Методы, которые используются в HTTP, имеют сходства с инструкциями, которые передаются в виде сообщения серверу. Это специальное слово на английском языке.

Метод GET. Его используют для запроса информации с ресурса. Именно с него начинаются все действия.
POST. С его помощью происходит отправка данных. Например, сообщение в социальной сети или комментарий, браузер помещает в тело POST-запроса и отправляет серверу.
HEAD. Метод имеет сходства с первым, но выполняет легкую функцию. Он запрашивает только мета-данные, исключая из ответа сообщение. Методом пользуются, если хотят получить информацию о файлах без скачивания. Его используют, если хотят проверить работоспособность ссылок на сервере.
PUT. Загружает данные на URL. Передает большие объемы данных.
OPTIONS. Работает с конфигурациями сервера.
URI. Идентифицирует ресурс и содержит в себе URL.

Структура http ответа

Сервер отвечает на запросы клиента длинными сообщениями. Ответ состоит из нескольких строк, в которых указывается версия протокола, код статуса сервера (200). Он говорит о том, что изменилось на сервере за время обработки поступившего запроса:

Статус «двести» указывает на успешную обработку информации. После этого сервер отправляет документ клиенту. Остальные строчки запроса указывают на другую информацию о передаваемых сведениях.
Если файл не найден или не существует, сервер посылает клиенту код 404, его еще называют ошибкой.
Код 206 указывает на частичное скачивание файла, которое можно возобновить спустя время.
Код 401 свидетельствует об отказе в авторизации. Это означает, что запрашиваемая страница защищена паролем, который следует ввести для подтверждения входа.
О запрещенном доступе, говорит код 403. Запреты на просмотры, скачивание файлов или видео - распространенный ответ в Интернете.
Существуют также другие версии кодов: временное перемещение запрашиваемого файла, внутренняя ошибка сервера, окончательное перемещение. В этом случае, пользователь будет перенаправлен. Если появился код 500, это означает, что в работе сервера появились сбои.

URL - что это?

URL - это сердце веб-общения между клиентом и сервером. Запрос обычно отправляется через URL - единый указатель ресурсов. Структура запроса url очень проста. Она состоит из нескольких элементов: протокол http (заголовок), hoot (адрес сайта), port, resourte path и query.

Протокол доступен также для безопасного соединения https и обмена информацией. URL-адрес содержит информацию о размещении конкретного сайта в Интернете. Адрес включает в себя имя домена, путь к странице, а также ее название.

Основной недостаток работы с URL - это неудобное взаимодействие с латинским алфавитом, а также цифрами и символами. В SEO оптимизации играет не последнюю роль.

Активным пользователям компьютеров и разработчикам не помещает ознакомиться с некоторыми профессиональными рекомендациями, которые дают специалисты в этой области:

Обозначайте сроки годности файлов и документов, с учетом обновлений. Статистическая информация указывается в больших значениях max-age.
Отдельный документ должен быть доступен лишь по одному URL.
Если обновляете файл, который будет скачиваться пользователем, измените его имя и ссылку на него. Это гарантирует скачивание нового, а не устаревшего документа.
Заголовки Last-Modified должны соответствовать настоящей дате последних изменений содержания. Не следует пересохранять страницы и документы, если не будете их менять.
Используйте POST-запросы лишь там, где это нужно. Сведите к минимуму работу с SSL.
Заголовки перед отправкой сервером следует проверять плагином REDbot.