W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

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

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 25 Apr 2014 10:30:42 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <7329C3FD-87B9-4358-B546-49CFE9C75FDC@mnot.net>
To: "Julian F. Reschke" <julian.reschke@gmx.de>
Re-visiting this; I still think we can close #424 with no action. Any disagreement?

Regards,


On 25 Mar 2014, at 10:36 am, Mark Nottingham <mnot@mnot.net> wrote:

> 
> On 21 Mar 2014, at 6:01 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
>>>>> 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.
> 
> That seems to make sense, but it isn't something specific to HTTP/2, and it's extending the semantics of a HTTP/1 header field. That sounds like a new spec that updates p2-semantics.
> 
> Julian, do you want to sketch that out so people can have a look?
> 
> Cheers,
> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Friday, 25 April 2014 00:29:44 UTC

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