Структурные единицы

HTTP/1.1 позволяет клиенту запросить только часть объекта (диапазон). HTTP/1.1 использует структурные единицы, определяющие выделение части объекта, в полях заголовка Range и ContentRange. Объект может быть разбит на фрагменты с использованием различных структурных единиц.

rangeunit = bytesunit | otherrangeunit bytesunit = "bytes" otherrangeunit = token

Единственной структурной единицей, определенной в HTTP/1.1, является bytes. HTTP/1.1 реализации могут игнорировать диапазоны, специфицированные с использованием других структурных единиц. Стандарт HTTP/1.1 сконструирован так, чтобы позволить реализацию приложений, которые не зависят от знания диапазонов.

Http сообщение. Типы сообщений

Сообщения HTTP включают в себя запросы клиента к серверу и отклики сервера клиенту.

HTTPmessage = Request | Response ; HTTP/1.1 messages

Сообщения запрос и отклик используют общий формат сообщений RFC-822 [7.9] для передачи объектов (поле данных сообщения). Оба типа сообщений состоят из стартовой строки, одного или более полей заголовка (также известные как "заголовки"), пустой строки (то есть, строка, содержащая CRLF ), отмечающей конец полей заголовка, а также опционного тела сообщения.

genericmessage = startline *messageheader CRLF [ messagebody ] startline = RequestLine | StatusLine

В интересах надежности рекомендуется серверам игнорировать любые пустые строки, полученные, когда ожидается RequestLine (строка запроса). Другими словами, если сервер читает протокольный поток в начале сообщения и получает сначала CRLF, он должен игнорировать CRLF.

Определенные некорректные реализации HTTP/1.0 клиентов генерируют дополнительные CRLF после запроса POST. Клиент HTTP/1.1 не должен посылать CRLF до или после запроса.

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

Поля заголовка HTTP, которые включают в себя общие поля заголовка, заголовка запроса, заголовка отклика и заголовка объекта, следуют тому же общему формату, что дан в разделе 3.1 RFC-822 [7.9]. Каждое поле заголовка состоит из имени, за которым следует двоеточие (":"), и поля значения. Поля имен безразличны в отношении использования строчных и прописных букв. Поле значения может начинаться с любого числа LWS, хотя один SP предпочтительнее. Поля заголовка могут занимать несколько строк, каждая новая строка должна открываться, по крайней мере, одним SP или HT. Рекомендуется, чтобы приложения следовали общему формату, если они создаются конструкциями HTTP, так как могут существовать некоторые реализации, которые не могут воспринимать ничего, кроме общих форматов.

Messageheader = fieldname ":" [ fieldvalue ] CRLF fieldname = token fieldvalue = *( fieldcontent | LWS )

fieldcontent = <OCTET'ы образуют значения поля и состоят из *TEXT или комбинаций лексем, tspecials и закавыченных строк>

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

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

го длина определяется следующим образом (в порядке приоритета).

1. Любое сообщение­отклик, которое не должно включать в себя тело сообщения (такое, как отклик 1xx, 204 и 304, а также любые отклики на запрос HEAD), всегда завершаются первой пустой строкой после полей заголовка, вне зависимости от присутствующих в сообщении полей заголовка объекта.

2. Если присутствует поле заголовка Transfer-Encoding и указано, что использовано фрагментное ("chunked") транспортное кодирование, тогда длина тела определяется выбранной схемой кодирования.

3. Если присутствует поле заголовка ContentLength, его значение в байтах и определяет длину тела сообщения.

4. Если сообщение использует тип cреды multipart/byteranges, который является самоограничивающим, тогда он и определяет длину. Этот тип среды не должен использоваться, если отправитель не знает, может ли получатель разобрать его. Присутствие в запросе заголовка Range с множественными спецификаторами диапазона подразумевает, что клиент может разобрать отклики типа multipart/byteranges.

5. Длина определяется сервером при закрытии связи. (Закрытие соединения не может применяться для обозначения конца тела запроса, так как это не оставит возможности для сервера послать отклик.)

Для совместимости с приложениями HTTP/1.0, запросы HTTP/1.1, содержащие тело запроса, должны включать корректное поле заголовка ContentLength. Когда запрос содержит тело сообщения, а поле ContentLength отсутствует, рекомендуется, чтобы сервер реагировал откликом 400 (плохой запрос), если он не может определить длину сообщения, или 411 (необходима длина), если он настаивает на получении корректного поля ContentLength.

Все приложения HTTP/1.1, которые получают объект ( entity ), должны понимать блочное ( chunked ) транспортное кодирование, таким образом, разрешая использование этого механизма для сообщений, когда длина сообщения не может быть определена заранее.

Сообщения не должны включать поле заголовка ContentLength и блочное транспортное кодирование одновременно. Если такое сообщение получено, поле ContentLength должно игнорироваться.

Когда в сообщении присутствует поле ContentLength и разрешено наличие тела сообщения, его значение поля должно строго соответствовать числу октетов в теле сообщения. Агенты пользователя HTTP/1.1 должны оповещать пользователя, если получено сообщение некорректной длины.