Длина сообщения. Когда тело сообщения message-body присутствует в сообщении, длина этого тела определяется одним из следующих методов в порядке старшинства 1. Любое сообщение ответа, которое не должно включать тело сообщения message-body например ответы с кодами состояния 1xx, 204, 304 и все ответы на запрос HEAD всегда завершается пустой строкой после полей заголовка, независимо от полей заголовка объекта entity-header fields, представленных в сообщении. 2. Если поле заголовка Transfer-Encoding присутствует и указывает на применение кодирования передачи chunked, то длина определяется кодированием по кускам chunked encoding . 3. Если поле заголовка Content-Length присутствует, то его значение представляет длину тела сообщения message-body в байтах. 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 агенты пользователя должны информировать пользователя в случае получения и обнаружения недопустимой длины. 4.5 Общие поля заголовка. Имеется несколько полей заголовка, которые применяются как для сообщений запросов, так и для сообщений ответов, но которые не применяются к передаваемому объекту.
Эти поля заголовка применяются только к передаваемому сообщению. general-header Cache-Control Connection Date Pragma Transfer-Encoding Upgrade Via Имена общих полей заголовка general-header fields могут быть надежно расширены только в сочетании с изменением версии протокола. Однако, новые или экспериментальные поля заголовка могут получить семантику общих полей заголовка general-header fields, если все стороны соединения распознают их как общие поля заголовка. Нераспознанные поля заголовка обрабатываются как поля заголовка объекта entity-header . 5. Запрос Request. Сообщение запроса сервера клиентом содержит в первой строке метод, который нужно применить к ресурсу, идентификатор ресурса и используемую версию протокола.
Request Request-Line general-header request-header entity-header CRLF message-body 5.1 Строка запроса Request-Line. Строка запроса Request-Line начинается с лексемы метода, затем следует запрашиваемый URI Request-URI , версия протокола и CRLF. Эти элементы разделяются SP. В строке запроса Request-Line не допустимы CR и LF, исключение составляет конечная последовательность CRLF. Request-Line Method SP Request-URI SP HTTP-Version CRLF 5.1.1