Re: JSON headers

[Cory Benfield <[e-mail]>]

> On 8 Jul 2016, at 18:49, Poul-Henning Kamp <[e-mail]> wrote:

Before I go any further, let me agree with Mike about this: I am generally 100% on the “structured serialisation format for header values” approach being discussed. I definitely want to see something in this space.

> Now lets go one step further:  Most implementations today support
> gzip, so the above should be the default if no Accept-Encoding
> header is present.  If you do not support gzip, you'll have to
> send:
> 
> 	Accept-Encoding: [ ]
> 
> Everybody else can avoid sending Accept-Encoding entirely.

This is one of those interesting decisions that has a tendency to make life very tricky for implementation authors. Generally speaking it is unwise to have the “do nothing” behaviour be totally wrong: that’s arguably what this would do. Specifically, if you write a HTTP implementation and don’t know anything about the Content-Encoding header, in the current model you shouldn’t be served anything weird. Basically, you’ll get data you recognise and expect. You need to opt-in to the compression. That means that RFC-compliant servers, written to expect that gzip will work in the absence of an Accept-Encoding header saying otherwise, will break naively-written clients that never considered Accept-Encoding.

I’m not sure this is a compelling reason *not* to do this. After all, this is not the only such behaviour that cannot be opted-into (see also chunked transfer encoding). It’s just a data point worth considering.

(I should also note that it’s weird that all Accept-Encoding header lists are implicitly terminated with “identity”, but the absence of such a header translates into “gzip”. That’s a strange inconsistency and I guarantee it’ll trip people up. It’s only an inconsistency though, and your rationale for it is well-reasoned.)

Cory