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

UptoLike

ВУЗ: 

ТГТУ | Тамбов

Составители: 

Рубрика: 

или другого полезного преобразования документа без потери идентификации основного медиати-
па и информации. Часто объект сохраняется в кодированной форме, затем передается, а потом
декодируется получателем:
content-coding = token
Все значения кодирования содержимого (content-coding) не чувствительны к регистру.
HTTP/1.1 использует значения кодирования содержимого (content-coding) в полях заголовка
Accept-Encoding и Content-Encoding. Хотя значение описывает кодирование содержимого, но, что
более важно – оно указывает, какой механизм декодирования потребуется для обратного процес-
са.
Internet Assigned Numbers Authority (IANA) действует как реестр для значений лексем коди-
рования содержимого (content-coding). Первоначально реестр содержал следующие лексемы:
• gzip – формат кодирования, производящий сжатие файла программой "gzip" (GNU zip),
описанный в RFC 1952. Это формат Lempel-Ziv кодирования (LZ77) с 32 разрядным CRC.
• Compress – формат кодирования, производимый общей программой "compress" для сжатия
UNIX файлов. Это формат адаптивного Lempel-Ziv-Welch кодирования (LZW).
Конечно, использовать названия программ для идентификации форматов кодирования не
желательно и может пересекаться с форматами, которые возникнут в последствии. Их использо-
вание объясняется исторической практикой. Для совместимости с предыдущими реализациями
HTTP, приложения должны рассматривать "x-gzip" и "x-compress" как эквиваленты "gzip" и
"compress", соответственно:
deflate – формат zlib, определенный в 1950, в комбинации с механизмом сжатия "deflate", опи-
санным в RFC 1951.
Новая лексема значения кодирования содержимого (content-coding) должна быть зарегистри-
рована; чтобы обеспечить взаимодействие между клиентами и серверами, спецификация алго-
ритма кодирования содержимого, необходимого для определения нового значения, должна быть
открыто опубликована и адекватна для независимой реализации, а также соответствовать цели
кодирования содержимого определенного в этом разделе.
9.4.4. HTTP СООБЩЕНИЕ (HTTP MESSAGE)
HTTP сообщения делятся на запросы клиента серверу и ответы сервера клиенту:
HTTP-message = Request | Response ; сообщения HTTP/1.1
Сообщения запроса и ответа используют обобщенный формат сообщения RFC 822 для пере-
сылки объектов (полезной нагрузки сообщения). Оба типа сообщений выглядят следующим обра-
зом: сначала идет начальная строка (start-line), затем один или несколько полей заголовка (назы-
ваемых также просто "заголовки"), затем пустая строка (то есть строка, равная CRLF), указы-
вающая конец полей заголовка, а затем, возможно, тело сообщения:
generic-message = start-line *message-header CRLF [ message-body ]
start-line = Request-Line | Status-Line
В интересах ошибкоустойчивости, серверам следует игнорировать все пустые строки, полу-
ченные перед строкой запроса (Request-Line). Другими словами, если сервер читает поток прото-
кола и в самом начале сообщения получает CRLF, то ему следует этот CRLF игнорировать.
Некоторые ошибочные реализации HTTP/1.0 клиентов генерируют дополнительные CRLF
после запроса POST. Стоит вновь повторить, что это явно запрещено нормальной записью Беку-
са-Наура. HTTP/1.1 клиент не должен добавлять дополнительные CRLF перед запросом и после
него.
Поля заголовков HTTP, которые включают поля общих заголовков (general-header), заголов-
ков запроса (request-header), заголовков ответа (response-header), и заголовков объекта (entity-
header), имеют такой же обобщенный формат, как тот, что описан в разделе 3.1 RFC 822. Каждое
поле заголовка состоит из имени поля, двоеточия (":") и значения поля. Имена полей не чувстви-
тельны к регистру. Значению поля может предшествовать любое число LWS, хотя предпочтите-

Страницы