- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Sat, 9 Jul 2016 17:22:59 +0100
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-Id: <F72E21BA-E891-4E1B-8535-385616431390@lukasa.co.uk>
> On 8 Jul 2016, at 18:49, Poul-Henning Kamp <phk@phk.freebsd.dk> 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
Received on Saturday, 9 July 2016 16:23:32 UTC