Сети и системы телекоммуникаций. Погонин В.А - 83 стр.

UptoLike

лен одиночный 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)]. Должно быть возможно объединить несколько таких полей за-
головка в одну пару "имя поля: значение поля" (не изменяя этим семантику сообщения) путем
присоединения каждого последующего значения поля к первому через запятые. Порядок, в кото-
ром получены поля с одинаковыми именами, имеет значение для интерпретации объединенного
значения поля, и, следовательно, прокси-сервер не должен изменять порядок значений этого поля
при пересылке.
Тело HTTP сообщения (message-body), если оно присутствует, используется для передачи тела
объекта, связанного с запросом или ответом. Тело сообщения (message-body) отличается от тела
объекта (entity-body) только в том случае, когда применяется кодирование передачи, что указы-
вается полем заголовка Transfer-Encodingы:
message-body = entity-body | <entity-body закодированно согласно
Transfer-Encoding>
Поле Transfer-Encoding должно использоваться для указания любого кодирования передачи,
примененного приложением в целях гарантирования безопасной и правильной передачи сообще-
ния. Поле Transfer-Encoding – это свойство сообщения, а не объекта, и, таким образом, может
быть добавлено или удалено любым приложением в цепочке запросов/ответов.
Правила, устанавливающие допустимость тела сообщения в сообщении, различаются для за-
просов и ответов.
Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля за-
головка Content-Length или Transfer-Encoding. Тело сообщения (message-body) может быть добав-
лено в запрос только тогда, когда метод запроса допускает тело объекта (entity-body).
Включать или не включать тело сообщения (message-body) в сообщение ответа зависит как от
метода запроса, так и от кода состояния ответа. Все ответы на запрос с методом HEAD не должны
включать тело сообщения (message-body), даже если присутствуют поля заголовка объекта (entity-
header), заставляющие поверить в присутствие объекта. Никакие ответы с информационными
кодами состояния 1xx, кодом 204 (Нет содержимого, No Content) и кодом 304 (Не модифицирован,
Not Modified) не должны содержать тела сообщения (message-body). Все остальные ответы содер-
жат тело сообщения, даже если оно имеет нулевую длину.
Когда тело сообщения (message-body) присутствует в сообщении, длина этого тела определя-
ется одним из следующих методов (в порядке старшинства):
1 Любое сообщение ответа, которое не должно включать тело сообщения (message-body) (на-
пример ответы с кодами состояния 1xx, 204, 304 и все ответы на запрос HEAD) всегда завершается
пустой строкой после полей заголовка, независимо от полей заголовка объекта (entity-header
fields), представленных в сообщении.
2 Если поле заголовка Transfer-Encoding присутствует и указывает на применение кодиро-
вания передачи "chunked", то длина определяется кодированием по кускам (chunked encoding).
3 Если поле заголовка Content-Length присутствует, то его значение представляет длину тела
сообщения (message-body) в байтах.