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

For my part I'm aiming for having gateways interop at least as well as they
do today.
That doesn't require us to disallow anything, but it would require putting
the uncompressed body-size in there when it is known.
That isn't the same as requiring uncompressed body-size.
-=R


On Tue, Mar 18, 2014 at 6:48 PM, Mark Nottingham <mnot@mnot.net> 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*.
>
> 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.
>
> Cheers,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>