Improving detection of unsupported Content-Codings, was: Support for gzip at the server #424 (Consensus Call)

On 2014-03-25 00:49, Roy T. Fielding wrote:
> ...
>>> 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?

I can.

> Please, no.  Changing CE transforms the content.  That means it is
> destructive unless done with full knowledge of the publication chain
> (i.e., how does the origin server know whether the client wants the
> representation to be compressed or just the transfer to be compressed?).

This is not about *changing* CE but simply about making it clearer how 
to signal errors (when the server doesn't support the CE used in the 
request).

> You should be talking about transfer encodings and advertised server
> settings, not CE.

Yes. That too.

Best regards, Julian

Received on Tuesday, 25 March 2014 07:53:45 UTC