Кодирование передачи: gzip против кодирования содержимого: gzip

Каково текущее положение дел, когда дело доходит до того, нужно ли делать

Transfer-Encoding: gzip

или

Content-Encoding: gzip

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

Последнее - то, что делают, например, Apache mod_deflate и IIS, если вы позволите ему позаботиться о сжатии. В зависимости от размера сжимаемого содержимого он будет выполнять дополнительные функции Transfer-Encoding: chunked.

Он также будет включать в себя Vary: Accept-Encoding, который уже намекает на проблему. Content-Encodingкажется, является частью объекта, поэтому изменение Content-Encodingсумм означает изменение объекта, то есть другой Accept-Encodingзаголовок означает, например, что кеш не может использовать свою кэшированную версию идентичного объекта.

Есть ли определенный ответ на этот вопрос, который я пропустил (и который не похоронен внутри сообщения в длинной цепочке какой-нибудь группы новостей apache)?

Мое текущее впечатление:

• Transfer-Encoding на самом деле будет правильным способом сделать то, что в основном делается с Content-Encoding существующими серверными и клиентскими реализациями.
• Content-Encoding из-за своего семантического значения несет в себе несколько проблем (что должен делать сервер, ETagкогда он прозрачно сжимает ответ?)
• Причина в том, что это курица и яйцо: браузеры не поддерживают ее, потому что серверы не поддерживают ее, потому что браузеры не поддерживают ее.

Итак, я предполагаю, что правильным способом будет Transfer-Encoding: gzip(или, если я дополнительно разделю тело, оно станет Transfer-Encoding: gzip, chunked ). И нет причин трогать Varyили ETagили любой другой заголовок в этом случае, поскольку это вещь транспортного уровня.

На данный момент меня не слишком заботит "переход за шагом" Transfer-Encoding, то, что, кажется, беспокоит других в первую очередь, потому что прокси-серверы могут распаковывать и пересылать несжатые данные клиенту. Однако прокси-серверы могут пересылать его как есть (сжатый), если исходный запрос имеет правильный Accept-Encodingзаголовок, что для всех известных мне браузеров является заданным.

Кстати, этой проблеме как минимум десять лет, см., Например, https://bugzilla.mozilla.org/show_bug.cgi?id=68517 .

Мы будем благодарны за любые разъяснения по этому поводу. И с точки зрения того, что считается соответствующим стандартам, и с точки зрения практичности. Например, клиентские библиотеки HTTP, поддерживающие только прозрачное «Content-Encoding», будут аргументом против практичности.

Цитата Роя Т. Филдинга , одного из авторов RFC 2616:

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

Источник: https://issues.apache.org/bugzilla/show_bug.cgi?id=39727#c31

Другими словами: не выполняйте кодирование содержимого на лету , используйте вместо этого Transfer-Encoding!

Изменить: то есть, если вы не хотите предоставлять сжатый контент клиентам, которые понимают только Content-Encoding . К сожалению, их большинство. Но имейте в виду, что вы покидаете области спецификации и можете столкнуться с проблемами, такими как упомянутая Филдингом, а также другими, например, когда задействованы кэширующие прокси.

Правильное использование, как это определено в RFC 2616 и фактически реализованы в дикой природе, для клиента , чтобы послать Accept-Encodingзаголовок запроса (клиент может указать несколько кодировок). Затем сервер может и только тогда закодировать ответ в соответствии с кодировками, поддерживаемыми клиентом (если данные файла еще не сохранены в этой кодировке), указать в Content-Encodingзаголовке ответа, какая кодировка используется. Затем клиент может считывать данные из сокета на основе Transfer-Encoding(т. Е. chunked), А затем декодировать их на основе Content-Encoding(т. Е. gzip).

Итак, в вашем случае клиент отправит Accept-Encoding: gzipзаголовок запроса, а затем сервер может решить сжать (если еще не) и отправить Content-Encoding: gzipи, возможно, Transfer-Encoding: chunkedзаголовок ответа.

И да, Transfer-Encodingзаголовок можно использовать в запросах, но только для HTTP 1.1, который требует, чтобы реализации как клиента, так и сервера поддерживали chunkedкодирование в обоих направлениях.

ETagоднозначно идентифицирует данные ресурса на сервере, а не фактически передаваемые данные. Если данный ресурс URL меняет свое ETagзначение, это означает, что данные на стороне сервера для этого ресурса изменились.