Пример. Запрос/ответ по HTTP

Метод

Для версии протокола HTTP/1.1 поле Метод в запросе может быть следующим:

• OPTIONS. Возвращает методы HTTP, которые поддерживаются сервером. Этот метод может служить для определения возможностей веб-сервера.
• GET. Запрашивает содержимое указанного ресурса. Запрашиваемый ресурс может принимать параметры (например, поисковая система может принимать в качестве параметра искомую строку). Они передаются в строке URI (например: http://www.example.net/resource?param1=value1&param2=value2). Согласно стандарту HTTP, запросы типа GET считаются идемпотентными — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.
• HEAD. Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Это полезно для извлечения метаданных, заданных в заголовках ответа, без пересылки всего содержимого.
• POST. Передаёт пользовательские данные (например, из HTML-формы) заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. В отличие от метода GET, метод POST не считается идемпотентным, то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).
• PUT. Загружает указанный ресурс на сервер.
• DELETE. Удаляет указанный ресурс.
• TRACE. Возвращает полученный запрос так, что клиент может увидеть, что промежуточные сервера добавляют или изменяют в запросе.

CONNECT. Для использования вместе с прокси-серверами, которые могут динамически переключаться в туннельный режим SSL.

В основном используются методы GET и POST.

Код ответа

На запрос клиента сервер посылает в ответ код состояния - целое число из 3 арабских цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая указывает на причину именно такого ответа.

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и все они описаны в соответствующих документах RFC. Введение новых кодов должно производится только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.

В настоящее время выделено пять классов кодов состояния.

• 1xx Informational (Информационный). В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего серверу отправлять не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.
• 2xx Success (Успешно). Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.
• 3xx Redirection (Перенаправление). Коды статуса класса 3xx сообщают клиенту, что для успешного выполнения операции нужно произвести следующий запрос к другому URI. В большинстве случаев новый адрес указывается в поле Location заголовка. Клиент в этом случае должен, как правило, произвести автоматический переход. Обратите внимание, что при обращении к следующему ресурсу можно получить ответ из этого же класса кодов. Может получиться даже длинная цепочка из перенаправлений, которые, если будут производиться автоматически, создадут чрезмерную нагрузку на оборудование. Поэтому разработчики протокола HTTP настоятельно рекомендуют после второго подряд подобного ответа обязательно запрашивать подтверждение на перенаправление у пользователя (раньше рекомендовалось после 5-го). За этим следить обязан клиент, так как текущий сервер может перенаправить клиента на ресурс другого сервера. Клиент также должен предотвратить попадание в круговые перенаправления.
• 4xx Client Error (Ошибка клиента). Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов кроме HEAD сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
• 5xx Server Error (Ошибка сервера). Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

Заголовки

Заголовки HTTP — это строки, каждая из которых состоит из имени параметра, за которым следует двоеточие и его значение. Они несут различную информацию о данных для браузера или для серверных программ (таких, как CGI-приложения). Между заголовками и телом обязательно должна быть пустая строка.

Разделим множество заголовков HTTP на заголовки запроса и заголовки ответа. Не полный список заголовков, описанных в RFC 2616 для HTTP/1.1, представлен ниже в таблицах:

Рассмотрим HTTP диалог между веб-браузером пользователя {строка идентификации Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5} и веб-сервером хоста www.mail.ru.

Данные HTTP заголовков получены с помощью Firefox дополнения — Live HTTP Headers.

Запрос от пользователя по URL www.mail.ru:

GET / HTTP/1.1

Host: www.mail.ru

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Cookie: mrcu=498448140CF97175844CA88EBD5A; p=e2kCAMuv8gAA; Mpop=1209265607:7f5a7900564f4c72190502190a1d00051c07074f6a5d5e465e0f0c01051d000103184249664f5f115c565c5b1b4341:[e-mail]:-; t=obLD1AAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAQAAEBngcA

Ответ сервера на запрос:

HTTP/1.x 200 OK

Date: Sun, 27 Apr 2008 08:53:46 GMT

Server: Apache/1.3.31 (Unix) mod_deflate/1.0.21 rus/PL30.20

Set-Cookie: Mpopl=1200751000; expires=Sun, 27 Apr 2008 09:08:46 GMT; path=/; domain=.mail.ru

Set-Cookie: mrcu=498448140CF97175844CA88EBD5A; expires=Tue, 12 Aug 2036 09:08:40 GMT; path=/; domain=.mail.ru

Expires: Mon, 26 Jul 1997 05:00:00 GMT

Cache-Control: no-cache, no-store, must-revalidate

Pragma: no-cache

Last-Modified: Tue, 12 Aug 2036 09:08:40 GMT

Connection: close

Transfer-Encoding: chunked

Content-Type: text/html; charset=koi8-r

Content-Encoding: gzip

Vary: user-agent

(Тело ответа: текст, html-код, данные и т.п.)

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

Дата добавления: 2014-01-07