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

On 2014-03-25 00:36, Mark Nottingham 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,

Done here:

   http://tools.ietf.org/html/draft-reschke-http-cice-00

Best regards, Julian

Received on Saturday, 10 May 2014 13:29:48 UTC