RFC: 2068
Оригинал: Hypertext Transfer Protocol - HTTP/1.1
Другие версии: RFC 2616
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Алексей Симонов

4.2. Заголовки сообщений

Поля заголовков HTTP, которые включают поля общих заголовков (general-header) (раздел 4.5), заголовков запроса (request-header) (раздел 5.3), заголовков ответа (response-header) (раздел 6.2), и заголовков объекта (entity-header) (раздел 7.1), имеют такой же обобщенный формат, что описан в разделе 3.1 RFC 822 [9]. Каждое поле заголовка состоит из имени, двоеточия (":") и значения поля. Имена полей не чувствительны к регистру. Значению поля может предшествовать любое число LWS, хотя предпочтителен одиночный SP. Поля заголовка могут занимать несколько строк. При этом каждая следующая строка начинается по крайней мере одним SP или HT. Приложениям СЛЕДУЕТ придерживаться "общей формы" ("common form") при генерации HTTP конструкций, так как могут существовать реализации, которые не в состоянии принимать что-либо кроме общих форм.

message-header = field-name ":" [ field-value ] CRLF

field-name     = token
field-value    = *( field-content | LWS )

field-content  = <октеты, составляющие значение поля и
                  состоящие или из *TEXT или из комбинаций
                  лексем, tspecials, и quoted-string>

Порядок, в котором получены поля заголовка с различными именами не имеет значения. Однако "хорошая практика" заключается в том, что сначала посылаются поля общих заголовков, затем поля заголовков запроса или заголовков ответа, и, наконец, поля заголовков объекта.

Несколько полей заголовка с одиннаковыми именами могут присутствовать в сообщении тогда, и только тогда, когда все значения полей, входящих в заголовок, определяют разделенный запятыми список [то есть #(value)]. ДОЛЖНО быть возможно объединить несколько таких полей заголовка в одну пару "имя поля: значение поля" (не измененяя этим семантику сообщения) присоединяя каждое последующее значение поля к первому через запятые. Порядок, в котором получены поля с одинаковыми именами, имеет значение для интерпретации объединенного значения поля, и, следовательно, прокси-сервер НЕ ДОЛЖЕН изменять порядок значений этого поля при пересылке.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.