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

On 19 Mar 2014, at 10:33 pm, Julian Reschke <julian.reschke@gmx.de> wrote:

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

Right now this falls into 415 Unsupported Media Type:

"""
   The 415 (Unsupported Media Type) status code indicates that the
   origin server is refusing to service the request because the payload
   is in a format not supported by this method on the target resource.
   The format problem might be due to the request's indicated Content-
   Type or Content-Encoding, or as a result of inspecting the data
   directly.
"""

So, it could be a new status code (that takes "or Content-Encoding" out of the definition of 415), or it could be a header on 415 that further refines its semantics.


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

We've had repeated attempts to use the HTTP/2 effort to modify HTTP semantics, and we've repeatedly rejected them. As Chair, I get very concerned when people try to make HTTP/2 a trojan horse for "improving" a particular situation, because the experience with new features layered into HTTP/1.1 this way (e.g., expect/continue, pipelining) was poor, and also because we'll be on a slippery slope to having lots of other people throw in their hobby features too.

In truth, I'm not entirely happy about the requirement for clients to support compressed responses, but tolerate it both because we have broad support for it, and its integration is relatively simple; it might require intermediaries to selectively decompress for 1.1 clients, but that's pretty straightforward.

This proposal does not enjoy broad support, and its integration is problematic; you'd be asking intermediaries to buffer, and to translate status codes from existing servers -- a dodgy proposition at best. For these reasons, I don't see consensus to add it.



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

Uh, no. It is perfectly legitimate and conforming to send 411, in that it's interoperable. At most we might use a SHOULD to encourage certain behaviour that's more *optimal*, but I don't think this kind of optimisation is an appropriate use of a MUST.

As Roy said, part of the confusion here is due to the difference between a server implementation and a resource implementation.


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

You mean a feature request?

--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 20 March 2014 23:58:25 UTC