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

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