Начальная строка сообщения клиентского запроса

Начальная строка сообщения клиентского запроса состоит из трех полей, разделенных пробелами. Ее формат таков: метод - URI - версия_протокола.
Важно уяснить, что любой HTTP-запрос, таким образом, содержит в себе URI (Uniform Resource Identifier, единообразный идентификатор ресурса) объекта, к которому требуется получить тот или иной вид доступа. Требования к формату URI будут рассмотрены чуть ниже. Предлагаю обсудить назначение и формат каждого из полей строки запроса по порядку.
Метод — это команда HTTP, определяющая цель запроса, т. е. указывающая серверу, какое действие необходимо произвести с запрашиваемым ресурсом.
Спецификация HTTP 1.1 явно описывает 8 методов. Помимо них, клиенты и серверы могут поддерживать расширенные, не предопределенные спецификацией методы.
Представляем перечень методов, предусмотренных описанием протокола HTTP 1.1.
? OPTIONS — дает клиенту возможность запросить информацию об опциях и/или требованиях, связанных с ресурсом или возможностями сервера, не производя никаких действий над ресурсом и не инициируя его загрузку.
? GET — позволяет получить содержимое объекта, идентифицируемого при помощи запрашиваемого URI. Если этот URI обращается к процессу, генерирующему данные, то в теле ответа должны содержаться сами эти данные, а не код породившей их программы.
? HEAD — идентичен методу GET, за исключением того, что сервер не должен возвращать в составе своего ответа тело сообщения. Данный метод используется для того, чтобы клиент мог получить метаинформацию об объекте запроса без непосредственной пересылки этого объекта.
? POST — используется для передачи серверу данных, которые требуется так или иначе связать с запрашиваемым ресурсом, в теле сообщения HTTP-запроса. Фактическое действие метода POST определяется на усмотрение сервера в зависимости от типа запрашиваемого ресурса. В большинстве случаев на практике этот метод применяется для отправки информации, полученной от пользователя при посредстве HTML-формы, на обработку при помощи некоторого веб-приложения стороны сервера.
? PUT — применяется для того, чтобы разместить объект, передаваемый в теле HTTP-запроса, по адресу, определяемому запрашиваемым URI.
? DELETE — позволяет удалить ресурс, идентифицируемый запрашиваемым URI.
? TRACE — предписывает серверу отразить запрос клиента, отправив его в неизменном виде в теле сообщения HTTP-ответа. Данный метод используется для отладочных целей.
? CONNECT — предназначен для работы с туннелирующими прокси-серверами, например, при использовании SSL (Secure Socket Layer) — протокола, обеспечивающего защищенный обмен сообщениями благодаря применению шифрования и механизмов взаимного опознания клиента и сервера.
Методы GET и HEAD, согласно спецификации HTTP 1.1, должны поддерживаться всеми веб-серверами. Остальные методы являются опциональными.
Нас в дальнейшем будут интересовать, в основном, только методы GET и POST, поскольку только они способны привести к загрузке веб-страницы (в том числе и динамически сгенерированной) в окошко браузера.
Особенности практического применения этих методов при разработке веб-приложений будут детально обсуждаться в главе 5.
Примечание
Многим читателям наверняка будет интересно, что первоначальная версия протокола HTTP (0.9) предусматривала один-единственный метод — GET.
Спецификация HTTP 1.0 определила три основных метода — GET, HEAD и POST. В приложении к ней описываются дополнительные методы PUT, DELETE, LINK и UNLINK. Последние два метода, однако, не унаследованы спецификацией HTTP 1.1 в силу того, что они так и не нашли себе практического применения.
Поле URI в контексте строки запроса, соответствующего протоколу HTTP 1.1, может представлять собой:
? символ звездочки (*). Применяется в том случае, когда запрос обращается не к частному ресурсу (например, файлу или каталогу), а к серверу вообще, при использовании метода, допускающего такое обращение (примером может являться метод OPTIONS);
? абсолютный URI, например bhv.ru/books/book.php?id=12736;
? абсолютный путь к ресурсу, например /books/book.php?id=12736;
? разделенные двоеточием имя хоста и номер порта сервера, с которым требуется установить соединение (используется только методом CONNECT), например bhv.ru:80.
Примечание
Спецификация HTTP 1.0 допускает только два возможных формата поля URI: абсолютный URI и абсолютный путь.
Когда HTTP-запрос осуществляется через посредство прокси-сервера, клиент обязан передавать в строке запроса абсолютный URI ресурса с указанием имени схемы и адреса хоста.
Если соединение с веб-сервером осуществляется без посредничества прокси-сервера, клиент должен отправить в поле URI строки запроса абсолютный путь к ресурсу, а имя хоста и номер порта (в том случае, когда сервер использует нестандартный порт) передать как содержимое поля заголовка Host. О заголовках мы побеседуем чуть позже.
Примечание
Ожидается, что в последующих версиях протокола HTTP возможность использования формата абсолютного пути в начальных строках сообщений запроса будет упразднена; вместо этого в любых случаях нужно будет указывать абсолютный URI.
Веб-серверы, поддерживающие спецификацию HTTP 1.1, должны принимать такие запросы.
Следует заметить, что протокол HTTP сам по себе не налагает никаких ограничений на длину поля URI. Однако на практике длина URI запроса ограничивается браузерами, прокси- и веб-серверами. Так, некоторые устаревшие разновидности перечисленного ПО (к счастью, уже почти забытые) могли работать только с адресами длиной до 255 символов. Впрочем, применять URI длиной более килобайта и в наше время можно только на свой страх и риск.
Версия протокола HTTP, указываемая в строке запроса, состоит из аббревиатуры HTTP, косой черты и номера, составленного из двух цифр, разделенных точками, например, HTTP/1.0, HTTP/1.1.
Примеры реальных строк запроса:
GET / HTTP/1.0
HEAD / HTTP/1.0
GET /yandsearch?rpt=rad&text=%E2%E5%E1-%F2%E5%F5%ED%EE%EB%EE%E3%E8%E8
? HTTP/1.1
POST /cgi-bin/guestbook.cgi HTTP/1.1
GET bhv.ru/ HTTP/1.1
В первом случае запрашивается корневой каталог дерева документов сервера с использованием метода GET в рамках протокола HTTP 1.0. В ответ на этот запрос, скорее всего, в теле HTTP-ответа сервера будет передан HTML-код главной страницы сайта, называемой иначе индексной (index — указатель, оглавление; индексная страница, таким образом, в дословном переводе — страница оглавления каталога). Веб-сервер определяет, какой именно объект является индексной страницей того или иного каталога, в соответствии со своими настройками, которые могут быть переопределены администратором. Чаще всего употребляется имя index.html.
Во втором примере аналогичный запрос производится с применением метода HEAD. В случае успешного выполнения этого запроса клиент получит от сервера сообщение ответа, не содержащее в своем составе тела, но включающее в себя заголовки, идентичные переданным в первом случае.
Третий пример иллюстрирует использование более сложного идентификатора ресурса в строке запроса, переданного методом GET в рамках протокола HTTP 1.1. Как мы видим, абсолютный путь дополняется именами и значениями параметров, полученных от пользователя при помощи веб-формы, предназначенной для ввода поискового запроса. Как многие догадались, речь идет о поиске от «Яндекса».
Четвертый пример демонстрирует начальную строку запроса, отправляемого серверу с помощью метода POST при использовании протокола HTTP 1.1. В теле запроса, скорее всего, содержится текст отзыва, полученный от пользователя при посредстве веб-формы и передаваемый CGI-скрипту с говорящим названием guestbook.cgi («гостевая книга») для добавления к ранее оставленным комментариям.
Наконец, в пятом примере вместо абсолютного пути используется абсолютный URI с указанием имени схемы и адреса хоста. Скорее всего, в данном случае общение между браузером и веб-сервером осуществляется при посредничестве прокси-сервера.


© 2008-2018 ОптимизацияВебСайтов.ру


Любое использование текстового и графического контента сайта без активной ссылки на источник не доскается.