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: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 21 Mar 2014 08:01:07 +0100
Message-ID: <532BE3B3.3000506@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 2014-03-21 00:58, Mark Nottingham wrote:
> 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.

Ah. I had forgotten that we added this to the description of 415.

So if we want to go down that route, we could recommend a 415 and in 
addition elevate "Accept-Encoding" to a response header field that could 
be used with 415.

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

No, I meant bug report :-)

Best regards, Julian
Received on Friday, 21 March 2014 07:01:40 UTC

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