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.edu01 HTTP/1.1
был бы передан прокси-сервером в виде
OPTIONS * HTTP/1.1 Host: www.ics.uci.edu01
после соединения с портом 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.