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

LGTM. I’d tweak these to paragraphs:

>    This specification extends that definition to allow "Accept-Encoding"
>    as response header field as well.  When present, it indicates what
>    content codings a server is willing to accept in requests.  In
>    particular, a field value that contains "identity" only implies that
>    no content codings are supported at all.
> 
>    Note that this information applies to the resource to which the
>    request was addressed.  The set of supported encodings might vary for
>    different resources on the same server, and could also vary depending
>    on other aspects of the request (such as the request method).

to:

“””
This specification extends that definition to allow "Accept-Encoding"
as a response header field as well.  When present, it indicates what
content codings a resource is willing to accept in future requests.  
A field value that only contains "identity" implies that no 
content codings are supported.

Note that this information is specific to the requested resource.  The
set of supported encodings might be different for resources on the 
same server, and could also change depending on other aspects of the 
request (such as the request method).
“””

Cheers,




On 10 May 2014, at 11:29 pm, Julian Reschke <julian.reschke@gmx.de> wrote:

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

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

Received on Monday, 12 May 2014 02:04:18 UTC