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

UptoLike

ВУЗ: 

ТГТУ | Тамбов

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

Рубрика: 

4 Если сообщение использует медиатип "multipart/byteranges", который саморазграничен, то
он и определяет длину. Этот медиа тип не должен использоваться, если отправитель не знает, спо-
собен ли получатель его обработать; присутствие в запросе заголовка Range с несколькими спе-
цификаторами диапазонов байтов (byte-range) подразумевает, что клиент может анализировать
multipart/byteranges ответы.
5 Длина определяется закрытием соединения сервером. (Закрытие соединения не может ис-
пользоваться для указания конца тела запроса, так как в этом случае у сервера не остается ника-
кой возможности послать обратно ответ).
Для совместимости с HTTP/1.0 приложениями HTTP/1.1 запросы, содержащие тело сообще-
ния (message-body) должны включать допустимое поле заголовка Content-Length, пока не извест-
но, что сервер является HTTP/1.1 совместимым. Если запрос содержит тело сообщения (message-
body), и Content-Length не указано, серверу следует послать ответ с кодом состояния 400 (Испор-
ченный Запрос, Bad Request), если он не может определить длину сообщения, или с кодом состоя-
ния 411 (Требуется длина, Length Required), если он настаивает на получении Content-Length.
Все HTTP/1.1 приложения, которые получают объекты, должны понимать кодирование пере-
дачи типа "chunked"; таким образом, разрешается использование данного механизма для сооб-
щений, длина которых не может быть определена заранее.
Сообщения не должны одновременно включать и поле заголовка Content-Length и применять
кодирование передачи типа "chunked". Если поступило сообщение с полем Content-Length и зако-
дированное с применением кодирования передачи "chunked", то поле Content-Length должно иг-
норироваться.
Если поле Content-Length присутствует в сообщении, которое допускает наличие тела сооб-
щения (message-body), то значение поля должно точно соответствовать числу октетов в теле со-
общения. HTTP/1.1 агенты пользователя должны информировать пользователя в случае получе-
ния и обнаружения недопустимой длины.
Имеется несколько полей заголовка, которые применяются как для сообщений запросов, так
и для сообщений ответов, но которые не применяются к передаваемому объекту. Эти поля заго-
ловка применяются только к передаваемому сообщению:
general-header = Cache-Control | Connection | Date | Pragma | Transfer-
Encoding | Upgrade | Via
Имена общих полей заголовка (general-header fields) могут быть надежно расширены только в
сочетании с изменением версии протокола. Однако, новые или экспериментальные поля заголов-
ка могут получить семантику общих полей заголовка (general-header fields), если все стороны со-
единения распознают их как общие поля заголовка. Нераспознанные поля заголовка обрабаты-
ваются как поля заголовка объекта (entity-header).
9.4.5. ЗАПРОС (REQUEST)
Сообщение запроса сервера клиентом содержит в первой строке: метод, который нужно при-
менить к ресурсу, идентификатор ресурса и используемую версию протокола:
Request = Request-Line*(general-header | request-header | entity-header )
CRLF [ message-body ]
Строка запроса (Request-Line) начинается с лексемы метода, затем следует запрашиваемый
URI (Request-URI), версия протокола и CRLF. Эти элементы разделяются SP. В строке запроса
(Request-Line) не допустимы CR и LF, исключение составляет конечная последовательность
CRLF:
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
Лексема метода указывает метод, который нужно применить к ресурсу, идентифицированно-
му запрашиваемым URI (Request-URI). Метод чувствителен к регистру:

Страницы