Почему Transfer-Encoding:Chunked отправляется вместо Content-Encoding:gzip для некоторых клиентов?

Question

Я был в замешательстве. У меня есть два ноутбука, которые подключаются к Интернету через одно модемное устройство. Для веб-серверов, которые включены gzip в них например microsoft.comОдна из моих систем (64-битная) получает заголовок ответа с Transfer-Encoding:chunked, Другой получить заголовок ответа в правильной форме с Content-Encoding:gzip, Зачем? Обе системы имеют Windows 7 SP1(одна из них 32-разрядная, а другая 64-разрядная). Я тестировал одну и ту же версию Chrome на обеих системах. Я также тестирую с FireFox и IE.

Answer 1

Потому что в кодировании передачи длина фрагментированного контента, который будет передаваться, не требуется. Данные разбиваются на части и отправляются по сети.

Со страницы Википедии:

Кодирование передачи по частям - это механизм передачи данных в версии 1.1 протокола передачи гипертекста (HTTP), в котором данные отправляются в виде серии "частей". Он использует HTTP-заголовок Transfer-Encoding вместо заголовка Content-Length, который в противном случае требовался бы для более ранней версии протокола. Поскольку заголовок Content-Length не используется, отправителю не нужно знать длину содержимого, прежде чем он начнет передавать ответ получателю. Отправители могут начать передачу динамически сгенерированного контента, прежде чем узнают общий размер этого контента.

Размер каждого чанка отправляется непосредственно перед самим чанком, чтобы получатель мог определить, когда он закончил получать данные для этого чанка. Передача данных завершается окончательным фрагментом нулевой длины.

Закодированные данные

В следующем примере каждая вторая строка является началом нового чанка, с размером чанка в виде шестнадцатеричного числа, за которым следует \ r \ n в качестве разделителя строк.

4\r\n
Wiki\r\n
5\r\n
pedia\r\n
e\r\n
 in\r\n\r\nchunks.\r\n
0\r\n
\r\n

Примечание: размер чанка указывает размер только данных чанка. Это не включает в себя завершающий CRLF ("\r\n") в конце подсчитанных символов. В этом конкретном примере CRLF, следующий за "in", считается 2 к длине фрагмента 0xE (14), а CRLF в своей собственной строке также учитывается 2 к длине фрагмента 0xE (14). Символ точки в конце "чанков" - это 14-й символ, поэтому он является последним символом чанка длиной 0xE (14). CRLF, следующий за периодом, является конечным CRLF, поэтому он не учитывается при длине фрагмента 0xE (14).

Декодированные данные

Wikipedia in

chunks.