W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: h2#404 requiring gzip and/or deflate

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Tue, 25 Feb 2014 18:33:29 +0100
To: Cory Benfield <cory@lukasa.co.uk>
Cc: Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <hgkpg9t34o0s4gl9iltdflgfd8cj4uegq6@hive.bjoern.hoehrmann.de>
* Cory Benfield wrote:
>That's not entirely true. The difference between HTTP/1.1 and HTTP/2.0
>is that in HTTP/1.1 if I send `Accept-Encoding: identity', the server
>must not return me a compressed response. In HTTP/2.0, however, the
>server may always return a response compressed with gzip or deflate.
>This means all HTTP/2.0 user-agents must allow decompression of gzip
>and deflate encoded responses, because we cannot reliably inform
>upstream that we don't want them.
>
>Jesse and I want to step that back to say that servers may always
>return a response compressed with gzip only: any other compression
>must be explicitly requested. In this sitatuion, if I then send
>`Accept-Encoding: gzip' I'll only ever get gzip back, even if the
>origin of the entity body is a HTTP/1.1 host. This would allow me to
>rip my deflate/zlib code out as I can ensure that it won't be sent to
>me.

The Accept-Encoding header indicates preferences and honouring them is a
SHOULD, not a MUST. It is not unusual to ignore it, e.g. typical Apache
configurations would send .gz files with `Content-Encoding: gzip` and
would not fail content negotiation and would not decompress the file
automatically when the client is not prepared to accept `gzip`, and some
deliberate configure it this way, e.g. to conserve resources.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Tuesday, 25 February 2014 17:34:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC