Transfer-Encoding — Протокол HTTP
Иногда данные, передающиеся с сервера, могут быть достаточно большими. И более того, мы можем не знать их конечный размер. Например, если нужно скачать архив или во время видео-трансляции.
Для решения этой проблемы можно загрузить данные полностью в оперативную память на сервере, вычислить Content-Length и осуществить передачу. После того, как контент будет целиком принят браузером, тот его моментально отобразит.
Существует еще одно решение, которое позволяет надежно передавать данные, когда мы не знаем их конечный размер. По ссылке находится пример изображения, которое отрисовывается постепенно по мере того, как происходит передача данных. Для этого используется механизм передачи небольшими частями, чанками (англ. chunks), и специальный заголовок Transfer-Encoding со значением chunked.
В стандартном ответе мы получаем все body целиком и после этого его обрабатываем. Мы не можем обрабатывать его частями потому, что тогда будем вводить какие-то свои уникальные правила внутри протокола. Но при передаче чанками мы можем обрабатывать ответ до полного получения body.
Сделаем запрос к сайту httpwatch.com:
# вместо Content-Length здесь заголовок Transfer-Encoding Transfer-Encoding: chunked Content-Type: image/jpeg; charset=utf-8 Expires: -1 Server: Microsoft-IIS/10.0 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Arr-Disable-Session-Affinity: True Date: Fri, 10 Jul 2020 09:18:05 GMT 400 # длина чанка Какие-то данные первого чанка 400 Данные второго чанка 400 и так далее 0 # последний чанк нулевой длины Обратите внимание, что заголовки как всегда отделяются от тела запроса переводом строки. В начале каждого чанка указывается его размер. За ним располагаются данные и в конце чанка делается перевод строки, затем идет следующий чанк и так далее. Таким образом можно передавать сколько угодно чанков, время ограничено только таймаутами внутри сервера.
Чтобы завершить передачу, нужно передать последний чанк, который должен быть нулевой длины. После него делается два перевода строки и запрос считается полностью переданным.
Формат сообщений
Для отделения записей размеров блоков (частей) от их содержания используется разделитель CRLF (как строка: «\r\n»; как байты в формате HEX: 0x0D, 0x0A). Длина блока — это размер содержания блока, разделители CRLF не учитываются.
Открыть доступ
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно
- 130 курсов, 2000+ часов теории
- 1000 практических заданий в браузере
- 360 000 студентов
Наши выпускники работают в компаниях:
При попытке передать информацию с помощью Transfer-Encoding: chunked, клиентская сторона читает данные обычным способом
При отправке информации с помощью http-чанков посылаю клиенту вот такой набор заголовков:
static const char hdr[]= "HTTP/1.0 200 OK\r\n" "Transfer-Encoding: chunked\r\n" "Connection: keep-alive\r\n";
После этого добавляется заголовок с типом данных(Content-Type:) и закрывается двумя \r\n, за этим следуют сами чанки, которые формируются в этом методе:
std::string httpHandler::chunk_create(const std::string &block)
Проблема в том, что браузер не понимает, что я передаю информацию чанками, и вместо этого просто добавляет к html страничке размер файла и crlf(иными словами, не интерпритирует составленный чанк как чанк, а читает как информацию полученную без заголовка Transfer-Encoding: chunked).Если браузер не понимает, что информация передается чанками, то,я думаю, ошибка в заголовках. Вопрос в том, где я ошибся? Может стоит добавить еще заголовоки или исправить существующие(пробовал отправлять с заголовком Vary: Accept-Encoding)? Как исправить возникшую проблему?
Transfer-Encoding
Заголовок Transfer-Encoding указывает кодировку form, используемую для безопасной передачи payload body пользователю.
Примечание. HTTP/2 запрещает любое использование заголовка Transfer-Encoding, кроме специфичного для HTTP/2: «trailers» . HTTP 2 предоставляет свои собственные более эффективные механизмы потоковой передачи данных, чем передача по частям, и запрещает использование заголовка. Использование заголовка в HTTP/2, вероятно, может привести к определенному protocol error , поскольку протокол HTTP/2 запрещает использование.
Transfer-Encoding — это hop-by-hop header , который применяется к сообщению между двумя узлами, а не к самому ресурсу. Каждый сегмент многоузлового соединения может использовать разные значения Transfer-Encoding . Если вы хотите сжимать данные по всему соединению, используйте сквозной заголовок Content-Encoding .
При наличии в ответе на запрос HEAD без тела он указывает значение, которое применялось бы к соответствующему сообщению GET .
| Header type | Н14153Н, П25387П, К36246К |
|---|---|
| Запрещенное имя заголовка | yes |
Syntax
Transfer-Encoding: chunked Transfer-Encoding: compress Transfer-Encoding: deflate Transfer-Encoding: gzip // Several values can be listed, separated by a comma Transfer-Encoding: gzip, chunked
Directives
Данные отправляются сериями блоков. Заголовок Content-Length в этом случае опущен, и в начале каждого чанка вам нужно добавить длину текущего чанка в шестнадцатеричном формате, за которым следует ‘ \r\n ‘, а затем сам чанк, за которым следует еще один ‘ \r\n ‘. Завершающий фрагмент является обычным фрагментом, за исключением того, что его длина равна нулю. За ним следует трейлер, который состоит из (возможно, пустой) последовательности полей заголовка.
Формат, использующий алгоритм Lempel-Ziv-Welch (LZW). Имя значения было взято из программы сжатия UNIX, в которой реализован этот алгоритм. Подобно программе сжатия, которая исчезла из большинства дистрибутивов UNIX, это кодирование контента сегодня почти не используется браузерами, отчасти из-за проблемы с патентом (срок действия которого истек в 2003).).
Использование структуры zlib (определено в RFC 1950 ) с алгоритмом сжатия deflate (определено в RFC 1951 ).
Формат, использующий Lempel-Ziv coding (LZ77), с 32-битным CRC. Это изначально формат программы gzip UNIX. Стандарт HTTP/1.1 также рекомендует, чтобы серверы, поддерживающие такое кодирование контента, распознавали x-gzip как псевдоним в целях совместимости.
Examples
Chunked encoding
Кодирование по частям полезно, когда клиенту отправляются большие объемы данных, и общий размер ответа может быть неизвестен до тех пор, пока запрос не будет полностью обработан. Например, при создании большой таблицы HTML в результате запроса к базе данных или при передаче больших изображений.
Фрагментированный ответ выглядит так:
HTTP/1.1 200 OK Content-Type: text/plain Transfer-Encoding: chunked 7\r\n Mozilla\r\n 11\r\n Developer Network\r\n 0\r\n \r\n
Specifications
| Specification |
|---|
| HTTP/1.1 # field.transfer-encoding |
Transfer-Encoding
The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.
Note: HTTP/2 disallows all uses of the Transfer-Encoding header other than the HTTP/2 specific: «trailers» . HTTP 2 provides its own more efficient mechanisms for data streaming than chunked transfer and forbids the use of the header. Usage of the header in HTTP/2 may likely result in a specific protocol error as HTTP/2 Protocol prohibits the use.
Transfer-Encoding is a hop-by-hop header, that is applied to a message between two nodes, not to a resource itself. Each segment of a multi-node connection can use different Transfer-Encoding values. If you want to compress data over the whole connection, use the end-to-end Content-Encoding header instead.
When present on a response to a HEAD request that has no body, it indicates the value that would have applied to the corresponding GET message.
| Header type | Request header, Response header, Payload header |
|---|---|
| Forbidden header name | yes |
Syntax
Transfer-Encoding: chunked Transfer-Encoding: compress Transfer-Encoding: deflate Transfer-Encoding: gzip // Several values can be listed, separated by a comma Transfer-Encoding: gzip, chunked
Directives
Data is sent in a series of chunks. The Content-Length header is omitted in this case and at the beginning of each chunk you need to add the length of the current chunk in hexadecimal format, followed by ‘ \r\n ‘ and then the chunk itself, followed by another ‘ \r\n ‘. The terminating chunk is a regular chunk, with the exception that its length is zero. It is followed by the trailer, which consists of a (possibly empty) sequence of header fields.
A format using the Lempel-Ziv-Welch (LZW) algorithm. The value name was taken from the UNIX compress program, which implemented this algorithm. Like the compress program, which has disappeared from most UNIX distributions, this content-encoding is used by almost no browsers today, partly because of a patent issue (which expired in 2003).
Using the zlib structure (defined in RFC 1950), with the deflate compression algorithm (defined in RFC 1951).
A format using the Lempel-Ziv coding (LZ77), with a 32-bit CRC. This is originally the format of the UNIX gzip program. The HTTP/1.1 standard also recommends that the servers supporting this content-encoding should recognize x-gzip as an alias, for compatibility purposes.
Examples
Chunked encoding
Chunked encoding is useful when larger amounts of data are sent to the client and the total size of the response may not be known until the request has been fully processed. For example, when generating a large HTML table resulting from a database query or when transmitting large images.
A chunked response looks like this:
HTTP/1.1 200 OK Content-Type: text/plain Transfer-Encoding: chunked 7\r\n Mozilla\r\n 11\r\n Developer Network\r\n 0\r\n \r\n
Specifications
| Specification |
|---|
| HTTP/1.1 # field.transfer-encoding |
Browser compatibility
BCD tables only load in the browser
See also
- Accept-Encoding
- Content-Encoding
- Content-Length
- Header fields that regulate the use of trailers: TE (requests) and Trailer (responses).
- Chunked transfer encoding
Found a content problem with this page?
- Edit the page on GitHub.
- Report the content issue.
- View the source on GitHub.
This page was last modified on Apr 10, 2023 by MDN contributors.
Your blueprint for a better internet.
MDN
Support
- Product help
- Report an issue
Our communities
Developers
- Web Technologies
- Learn Web Development
- MDN Plus
- Hacks Blog
- Website Privacy Notice
- Cookies
- Legal
- Community Participation Guidelines
Visit Mozilla Corporation’s not-for-profit parent, the Mozilla Foundation.
Portions of this content are ©1998– 2023 by individual mozilla.org contributors. Content available under a Creative Commons license.