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

Re: Support for gzip at the server #424 (Consensus Call)

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 19 Mar 2014 12:48:00 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <DFC73FD3-5A74-4E03-8523-030DCD0D6CB1@mnot.net>
To: Roy Fielding <fielding@gbiv.com>

On 19 Mar 2014, at 8:01 am, Roy T. Fielding <fielding@gbiv.com> wrote:

> It would be a terrible mistake to limit HTTP/2 to the worst
> of old implementations.  That is the opposite of HTTP's design
> for flexible extensibility.  There are hundreds (if not thousands) of
> implementations of HTTP/1.1 that have no problem whatsoever with
> compression, chunked encoding, or any of the other features of HTTP.
> That is because the people installing them control the network in which
> those features are enabled, and can remove any products that get them
> wrong. HTTP/2 should focus on making features self-descriptive,
> rather than inventing limitations on use.

I don't think anyone is talking about *limiting* what you can do in HTTP/2 here -- what's being discussed is whether server-side support for GZIP content-coding in requests should be *required*.

Everyone should keep in mind that the only way we can make such a restriction stick in all cases is to disallow 411 (Length Required) in HTTP/2 -- which I personally think is unrealistic in the extreme, considering how common it is. 

Finally, one point of data (based upon 5 minutes of testing) - Squid 2.HEAD (in 1.1 mode) will generate 411 for POST without a Content-Length automatically. It's still one of the most widely deployed intermediaries out there, IME.


Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 19 March 2014 01:48:27 UTC

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