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

Исходному серверу HTTP/1.1 рекомендуется заботиться о точном определении ресурса, идентифицированного Интернет­запросом, путем анализа Request-URI и поля заголовка Host.

Исходный сервер, который не разделяет ресурсы по запрашиваемым ЭВМ, может игнорировать значение поля заголовка Host.

Исходный сервер, который различает ресурсы с использованием имени ЭВМ, должен использовать следующие правила для определения ресурса в запросе HTTP/1.1.

1. Если Request-URI является absolute-URI, ЭВМ определена частью Request-URI. Любое значение поля заголовка Host в запросе должно игнорироваться.

2. Если Request-URI не является absolute-URI, а запрос содержит поле заголовка Host, ЭВМ определяется значением поля заголовка Host.

3. Если ЭВМ, так как это определено правилами 1 или 2, не является ЭВМ сервера, откликом должно быть сообщение об ошибке с кодом 400 (Плохой запрос — Bad Request).

Получатели HTTP/1.0запроса, где отсутствует поле заголовка Host, могут попытаться использовать эвристику (например, рассмотрение прохода URI на предмет уникальной конкретной ЭВМ), чтобы определить, какой конкретный ресурс запрошен.

Поля заголовка запроса

Поля заголовка запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте. Эти поля действуют как модификаторы запроса, с семантикой, которая эквивалентна параметрам, характеризующим метод языка программирования.

Requestheader = Accept | AcceptCharset | AcceptEncoding | AcceptLanguage | Authorization | From | Host | If-Modified-Since | If-Match | If-None-Match | If-Range | If-Unmodified-Since | Max-Forwards | Proxy-Authorization | Range | Referer | User-Agent

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

Отклик

После получения и интерпретации сообщениязапроса сервер реагирует, посылая HTTP сообщение­отклик.

Response (отклик) = StatusLine *( generalheader | responseheader | entityheader ) CRLF [ messagebody ]

Статусная строка

Первая строка сообщенияотклика является статусной строкой, состоящей из кода версии протокола, за которым следует числовой статусный код и его текстовое представление, все элементы разделяются символами SP (пробел). Никакие CRили LF не допустимы, за исключением завершающей последовательности CRLF.

StatusLine = HTTPVersion SP StatusCode SP ReasonPhrase CRLF

Статусный код и словесный комментарий

Элемент StatusCode представляет собой 3-х значный цифровой результирующий код попытки понять и исполнить запрос. Словесный комментарий ( ReasonPhrase ) предназначен для того, чтобы дать краткое описание статусного кода. Статусный код служит для использования автоматами, а словесный комментарий — для пользователей. Клиент не обязан рассматривать или отображать словесный комментарий.

Первая цифра статусного кода определяет класс отклика. Последние две цифры не имеют четко определенной функции. Существует 5 значений первой цифры:

• 1xx: Информационный — Запрос получен, процесс продолжается;

• 2xx: Успех (Success) — Запрос успешно получен, понят и воспринят;

• 3xx: Переадресация (Redirection) — Нужны дополнительные действия для завершения выполнения запроса;

• 4xx: Ошибка клиента (Client Error) — Запрос содержит синтаксическую ошибку или не может быть выполнен;

• 5xx: Ошибка сервера (Server Error) — Сервер не смог выполнить корректный запрос.

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

StatusCode = "100" ; Continue | "101" ; Switching Protocols | "200" ; OK | "201" ; Created | "202" ; Accepted | "203" ; NonAuthoritative Information | "204" ; No Content | "205" ; Reset Content | "206" ; Partial Content | "300" ; Multiple Choices | "301" ; Moved Permanently | "302" ; Moved Temporarily | "303" ; See Other | "304" ; Not Modified | "305" ; Use Proxy | "400" ; Bad Request | "401" ; Unauthorized | "402" ; Payment Required | "403" ; Forbidden | "404" ; Not Found | "405" ; Method Not Allowed | "406" ; Not Acceptable | "407" ; Proxy Authentication Required | "408" ; Request Timeout | "409" ; Conflict | "410" ; Gone | "411" ; Length Required | "412" ; Precondition Failed | "413" ; Request Entity Too Large | "414" ; Request-URI Too Large | "415" ; Unsupported Media Type | "500" ; Internal Server Error | "501" ; Not Implemented | "502" ; Bad Gateway | "503" ; Service Unavailable | "504" ; Gateway Timeout | "505" ; HTTP Version not supported | extensioncode Extensioncode = 3DIGIT ReasonPhrase = *

Статусные коды HTTP допускают расширение. HTTP приложения могут не понимать значение всех зарегистрированных статусных кодов, хотя такое понимание, очевидно, является желательным. Однако, приложения должны понимать класс любого статусного кода, который задается его первой цифрой, и воспринимать неузнанный отклик как x00. Неузнанный статусный отклик не должен заноситься в буфер. Например, если клиентом получен нераспознаваемый статусный код 431, он может предположить, что произошло что­то с запросом, и рассматривать отклик так, как если бы он равнялся 400. В таких случаях агентам пользователя рекомендуется предоставлять пользователю объект с откликом, который содержит текст, поясняющий причину создавшейся ситуации.