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

On 2014-03-19 02:48, Mark Nottingham wrote:
>
> 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*.

I think it would be good if we (a) encouraged servers to do it, and (b) 
clarified error handling if you don't.

1) Define a status code for "unsupported content-encoding" (plus maybe 
discovery via a Accept-Encoding header field that can be sent with it)

2) Require servers to either support gzip content encoding or fail the 
request with the new status code.

> 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.

So in 1.1, the description of 411 should have stated that this indicates 
a violation of a 1.1 requirement, fwiw.

> 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.

Is there a bug report for that yet?

Best regards, Julian

Received on Wednesday, 19 March 2014 11:33:48 UTC