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

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

generalheader = Cache-Control | Connection | Date | Pragma | Transfer-Encoding | Upgrade | Via

Имена полей общего заголовка могут быть расширены только при изменении версии протокола. Однако новые или экспериментальные поля заголовка могут использоваться при условии, если партнеры обмена способны их распознавать как поля общего заголовка. Неузнанные поля заголовка считаются полями заголовка объекта ( entity ).

Запрос

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

Request = RequestLine *( generalheader | requestheader | entityheader ) CRLF [ messagebody ]

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

Строка запроса начинается с лексемы метода, за которой следует Request-URI, версия протокола, и завершается строка последовательностью CRLF. Элементы разделяются символами SP. Символы CR или LF запрещены, кроме завершающей последовательности CRLF.

Request Line = Method SP Request-URI SP HTTPVersion CRLF

Метод

Лексема Method указывает на метод, который должен быть применен к ресурсу, обозначенному Request-URI. При записи метода использование строчных или прописных букв не безразлично.

Method = "OPTIONS" | "GET" | "HEAD" | "POST" | "PUT" | "DELETE" | "TRACE" | extensionmethod extensionmethod = token

Список методов, допустимых для ресурса, может быть специфицирован полем заголовка Allow. Возвращаемый код отклика всегда оповещает клиента, допустим ли метод для ресурса, так как набор допустимых методов может меняться динамически. Серверам рекомендуется возвращать статусный код 405 (Метод не допустим), если метод известен серверу, но не приемлем для запрашиваемого ресурса, и 501 (Не применим), если метод не узнан или не приемлем для сервера. Список методов, известных серверу, может быть представлен в поле заголовка отклика Public.

Методы GET и HEAD должны поддерживаться всеми серверами общего назначения.

Uri запроса

URI запроса является универсальным идентификатором ресурса и идентифицирует ресурс, который запрашивается.

Request-URI = "*" | absoluteURI | abs_path

Три опции для Request-URI зависят от природы запроса. Звездочка "*" означает, что запрос приложим не к заданному ресурсу, но к самому серверу, и допустим только, когда используемый метод не обязательно приложим к ресурсу. Примером может служить

OPTIONS * HTTP/1.1

Форма абсолютного URI необходима, когда запрос адресован к проксисерверу. Прокси­серверу посылается запрос переадресации с целью получения отклика. Заметьте, что прокси может переадресовать запрос другому прокси или серверу, указанному абсолютным URI. Чтобы избежать петель запросов, проксисервер должен быть способен распознавать все имена серверов, включая любые псевдонимы, локальные вариации и численные IP-адреса. Пример строки запроса представлен ниже:

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

Для того чтобы разрешить передачу абсолютных URI в запросах будущих версий HTTP, все серверы HTTP/1.1 должны уметь работать с запросами абсолютных форм URI.

Наиболее общей формой Request-URI является та, которая используется для идентификации ресурса на исходном сервере или внешнем порту сети. В этом случае абсолютный проход к URI должен быть занесен в 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, чтобы правильно интерпретировать запрос. Серверам рекомендуется откликаться на некорректный запрос Request-URI, соответствующим статусным кодом.

В запросах, которые они переадресуют, проксисерверы не должны переписывать abs_path -часть Request-URI каким­-либо способом, за исключением случая, описанного выше, когда нулевой abs_path заменяется на "*".

Правило "no rewrite" препятствует прокси изменить смысл запроса, когда исходный сервер некорректно использует незарезервированный URL символ для зарезервированных целей.

Следует остерегаться ситуации, когда некоторые предшествующие варианты проксисерверов HTTP/1.1 допускают перезапись Request-URI.