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

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

Поля заголовка отклика

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

Responseheader = Age
| Location
| Proxy-Authenticate
| Public
| Retry-After
| Server
| Vary
| Warning
| WWWAuthenticate

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

Объект (Entity)

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

В данном разделе как отправитель, так и получатель соотносятся к клиенту или серверу, в зависимости от того, кто отправляет и кто получает объект.

Поля заголовка объекта

Поля заголовка объекта определяют опционную метаинформацию о теле объекта или, если тело отсутствует, о ресурсе, идентифицированном в запросе.

Entityheader = Allow
| ContentBase
| Content
| ContentLanguage
| ContentLength
| ContentLocation
| ContentMD5
| ContentRange
| Content-Type
| Etag
| Expires
| Last-Modified
| extensionheader
extensionheader = messageheader

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

Тело объекта

Тела объекта (если они имеются), пересылаемые HTTPзапросом или откликом, имеют формат и кодировку, определенную полями заголовка объекта.

entitybody = *OCTET

Тело объекта присутствует в сообщении, только когда имеется тело сообщения. Тело объекта получается из тела сообщения путем декодирования любого транспортного кода (Transfer-Encoding), который может быть применен для обеспечения безопасной и корректной доставки.

Тип

Когда тело объекта включено в сообщение, тип данных этого тела определяется полями заголовка Content-Type и Content-Encoding. Они определяют два слоя, заданных моделью кодирования:

entitybody:= Content-Encoding(Content-Type(данные))

Content-Type специфицирует тип среды данных.

Content-Encoding может использоваться для индикации любого дополнительного кодирования содержимого поля данных, обычно для целей архивации, которая является особенностью запрашиваемого ресурса. По умолчанию никакого кодирования не применяется.

Любое HTTP/1.1 сообщение, содержащее тело объекта, должно включать поле заголовка Content-Type, определяющее тип среды для данного тела. Только в случае, когда тип среды не задан полем Content-Type, получатель может попытаться предположить, каким является тип среды, просмотрев содержимое и/или расширения имен URL, использованного для идентификации ресурса. Если тип среды остается неизвестным, получателю следует рассматривать его как application/octetstream (поток октетов).

Длина тела объекта равна длине тела сообщения, после того как произведено транспортное декодирование.