W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Making Implicit C-E work.

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Thu, 15 May 2014 09:07:22 +1000
Message-ID: <CACweHNAF4NkwVR24+_AWn3Et2Z8pBqZPc5M-YQr-Qwmj0dWDRA@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
I've just had a quick read through P2 and it appears, unless I've missed a
hidden reference somewhere, nothing actually forbids a sender from using an
unsupported content coding, as long as it includes the appropriate
Content-Encoding header.

So why not just change the current text to "SHOULD decompress" and let the
gateway do the best it can?

If the call is, for example, between ignoring a cache-control:no-transform
header and unzipping a payload, making the service unusable with a 40x
Unacceptable response (sorry I forget the code ATM. 406?), or just sending
the content-coded payload as is (which, BTW, sticks it to those extant 1.1
proxies that strip a-e headers), I think the gateway should be able to
choose what it thinks will work best. Especially if that choice can be
reconfigured over time (much easier than revising the spec and rolling out
a new gateway).
Received on Wednesday, 14 May 2014 23:07:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC