5 ‡апрос (Request).

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

           Request       = Request-Line              ; ђаздел 5.1
                           *( general-header         ; ђаздел 4.5
                            | request-header         ; ђаздел 5.3
                            | entity-header )        ; ђаздел 7.1
                           CRLF
                           [ message-body ]          ; ђаздел 7.2

5.1 ‘трока запроса (Request-Line).

‘трока запроса (Request-Line) начинаетсЯ с лексемы метода, затем следует запрашиваемый URI (Request-URI), версиЯ протокола и CRLF. ќти элементы разделЯютсЯ SP. ‚ строке запроса (Request-Line) не допустимы CR и LF, исключение составлЯет конечнаЯ последовательность CRLF.

          Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

5.1.1 Њетод (Method).

‹ексема метода указывает метод, который нужно применить к ресурсу, идентифицированному запрашиваемым URI (Request-URI). Њетод чувствителен к регистру.

          Method         = "OPTIONS"                ; ђаздел 9.2
                         | "GET"                    ; ђаздел 9.3
                         | "HEAD"                   ; ђаздел 9.4
                         | "POST"                   ; ђаздел 9.5
                         | "PUT"                    ; ђаздел 9.6
                         | "DELETE"                 ; ђаздел 9.7
                         | "TRACE"                  ; ђаздел 9.8
                         | extension-method

          extension-method = token

‘писок методов, применимых к ресурсу, может быть указан в поле заголовка Allow (раздел 14.7). ‚озврашаемый код состоЯниЯ ответа всегда сообщает клиенту, допустим ли метод длЯ ресурса в настоЯщее времЯ, так как набор допустимых методов может изменЯтьсЯ динамически. ‘ерверам ‘‹…„“…’ возвратить код состоЯниЯ 405 (Њетод не дозволен, Method Not Allowed), если метод известен серверу, но не применим длЯ запрошенного ресурса, и 501 (Ќе реализовано, Not Implemented), если метод не распознан или не реализован сервером. ‘писок методов, известных серверу, может быть указан в поле заголовка ответа Public (раздел 14.35).

Њетоды GET и HEAD „Ћ‹†Ќ› поддерживатьсЯ всеми универсальными (general-purpose) серверами. Ћстальные методы опциональны; однако, если вышеупомЯнутые методы реализованы, то они „Ћ‹†Ќ› иметь семантику, описанную в разделе 9.

5.1.2 ‡апрашиваемый URI (Request-URI).

‡апрашиваемый URI (Request-URI) - это …динообразный €дентификатор ђесурса (URL, раздел 3.2), который идентифицирует ресурс запроса.

          Request-URI    = "*" | absoluteURI | abs_path

’ри опции длЯ запрашиваемого URI (Request-URI) зависЯт от характера запроса. ‡вездочка "*" означает, что запрос обращаетсЯ не к специфическому ресурсу, а к серверу непосредственно, и допускаетсЯ только в том случае, когда используемый метод не обЯзательно обращаетсЯ к ресурсу. ‚ качестве примера:

          OPTIONS * HTTP/1.1

absoluteURI необходим, когда запрос производитсЯ через прокси-сервер. Џрокси-сервер перенаправлЯет запрос на сервер или обслуживает его, пользуЯсь кэшем, и возвращает ответ. Ћбратите внимание, что прокси-сервер ЊЋ†…’ переслать запрос другому прокси-серверу или непосредственно серверу, определенному absoluteURI. —тобы избежать зацикливаниЯ запроса прокси-сервер „Ћ‹†…Ќ быть способен распознавать все имена сервера, включаЯ любые псевдонимы, локальные разновидности, и числовые IP адреса. Request-Line может быть, например, таким:

          GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

—тобы обеспечить переход к absoluteURI во всех запросах в будущих версиЯх HTTP, все HTTP/1.1 серверы „Ћ‹†Ќ› принимать absoluteURI в запросах, хотЯ HTTP/1.1 клиенты будут генерировать их только в запросах к прокси-серверам.

Ќаиболее общаЯ форма Request-URI - та, котораЯ используетсЯ длЯ идентификации ресурса на первоначальном сервере или шлюзе. ‚ этом случае абсолютный путь URI (смотрите раздел 3.2.1, abs_path) „Ћ‹†…Ќ быть передан как Request-URI, а сетевое расположение URI (net_loc) „Ћ‹†ЌЋ быть передано в поле заголовка Host. „лЯ последнего примера клиент, желающий получить ресурс непосредственно с первоначального сервера должен создать TCP соединение на 80 порт хоста "www.w3.org" и послать строки:

          GET /pub/WWW/TheProject.html HTTP/1.1
          Host: www.w3.org

и далее остаток запроса. Ћбратите внимание, что абсолютный путь не может быть пустым; если оригинальный URI пуст, то он „Ћ‹†…Ќ запрашиватьсЯ как "/" (корневой каталог сервера).

…сли прокси-сервер получает запрос без пути в Request-URI, и метод запроса допускает форму запроса "*", то последний прокси-сервер в цепочке запросов „Ћ‹†…Ќ передать запрос, в котором Request-URI равен "*". Ќапример запрос

          OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1

был бы передан прокси-сервером в виде

          OPTIONS * HTTP/1.1
          Host: www.ics.uci.edu:8001

после соединениЯ с портом 8001 хоста "www.ics.uci.edu".

Request-URI передаетсЯ в формате, определенном в разделе 3.2.1. Џервоначальный сервер „Ћ‹†…Ќ декодировать Request-URI, чтобы правильно интерпретировать запрос. ‘ерверам ‘‹…„“…’ отвечать на недопустимые Request-URI соответствующим кодом состоЯниЯ.

‚ запросах, которые передаютсЯ далее, прокси-сервера никогда Ќ… „Ћ‹†Ќ› перезаписывать часть "abs_path" запрашиваемого URI (Request-URI), за исключением случаЯ, отмеченного выше, когда пустой abs_path заменЯетсЯ на "*", независимо от внутренней реализации прокси-сервера.

Ћбратите внимание: правило "ничто не перезаписывать" предохранЯет прокси-сервера от изменениЯ значениЯ запроса, в котором первоначальный сервер неправильно использует не зарезервированные символы URL длЯ своих целей. ђеализаторам следует знать, что некоторые до-HTTP/1.1 прокси-сервера, как известно, перезаписывали Request-URI.

5.2 ђесурс, идентифицируемый запросом.

Џервоначальные HTTP/1.1 сервера „Ћ‹†Ќ› учитывать, что точный ресурс, идентифицированный интернет-запросом определЯетсЯ исследованием как Request-URI, так и полЯ заголовка Host.

Џервоначальный сервер, который не позволЯет ресурсам отличатьсЯ по запрошенному хосту (host), ЊЋ†…’ игнорировать значение полЯ заголовка Host. (Ќо смотрите раздел 19.5.1 длЯ других требований по поддержке Host в HTTP/1.1).

Џервоначальный сервер, который различает ресурсы, основанные на запрошенном хосте (иногда называемые виртуальными хостами или vanity hostnames) „Ћ‹†…Ќ использовать следующие правила длЯ определениЯ запрошенного в HTTP/1.1 запросе ресурса:

…сли Request-URI - это absoluteURI, то хост - это часть Request-URI. ‹юбое значение полЯ заголовка Host в запросе „Ћ‹†ЌЋ игнорироватьсЯ.
…сли Request-URI - не absoluteURI, а запрос содержит поле заголовка Host, то хост определЯетсЯ значением полЯ заголовка Host.
…сли хоста, определенного правилами 1 или 2 не существует на сервере, код состоЯниЯ ответа „Ћ‹†…Ќ быть 400 (€спорченный ‡апрос, Bad Request).

Џолучатели HTTP/1.0 запроса, в котором недостает полЯ заголовка Host, ЊЋѓ“’ пытатьсЯ использовать эвристику (например, исследовать путь в URI на предмет уникальности на каком-либо из хостов) чтобы определить какой точно ресурс запрашиваетсЯ.

5.3 ЏолЯ заголовка запроса.

ЏолЯ заголовка запроса позволЯют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте. ќти полЯ действуют как модификаторы запроса с семантикой, эквивалентной параметрам вызова методов в Языках программированиЯ.

          request-header = Accept                   ; ђаздел 14.1
                         | Accept-Charset           ; ђаздел 14.2
                         | Accept-Encoding          ; ђаздел 14.3
                         | Accept-Language          ; ђаздел 14.4
                         | Authorization            ; ђаздел 14.8
                         | From                     ; ђаздел 14.22
                         | Host                     ; ђаздел 14.23
                         | If-Modified-Since        ; ђаздел 14.24
                         | If-Match                 ; ђаздел 14.25
                         | If-None-Match            ; ђаздел 14.26
                         | If-Range                 ; ђаздел 14.27
                         | If-Unmodified-Since      ; ђаздел 14.28
                         | Max-Forwards             ; ђаздел 14.31
                         | Proxy-Authorization      ; ђаздел 14.34
                         | Range                    ; ђаздел 14.36
                         | Referer                  ; ђаздел 14.37
                         | User-Agent               ; ђаздел 14.42

€мена полей заголовка запроса (Request-header) могут быть надежно расширены только в сочетании с изменением версии протокола. Ћднако, новые или экспериментальные полЯ заголовка могут получить семантику полей заголовка запроса (Request-header), если все стороны соединениЯ распознают их как полЯ заголовка запроса (Request-header). Ќераспознанные полЯ заголовка обрабатываютсЯ как полЯ заголовка объекта (entity-header).