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

RE: Making Implicit C-E work.

From: <K.Morgan@iaea.org>
Date: Sat, 17 May 2014 18:10:17 +0000
To: <matthew@kerwin.net.au>
CC: <ietf-http-wg@w3.org>, <C.Brunhuber@iaea.org>, <jgraettinger@chromium.org>, <martin.thomson@gmail.com>, <grmocg@gmail.com>, <mnot@mnot.net>
Message-ID: <0356EBBE092D394F9291DA01E8D28EC20112D9E021@sem002pd.sg.iaea.org>
On Saturday,17 May 2014 01:39, Matthew Kerwin wrote:

> On May 15, 2014 9:42 PM, <K.Morgan@iaea.org> wrote:

>> ... [Matthew's suggestion to lift the MUST requirement for intermediaries to decompress]

>> only makes sense _if_ you are assuming acceptance of Roberto's proposed

>> "uncompressed-*" headers solution. Otherwise this doesn't solve any of the problems

>> brought up by Matthew, Julian, myself and others with respect to etag, no-transform,

>> metadata within the entity body, etc...


> ... Right now a server is well within its rights to completely ignore any and all Accept-* headers;

I disagree. According to 'Section 5.3.4 Accept-Encoding' of HTTP-p2 [1], only if a client does not include an Accept-Encoding header, then a server can choose any encoding…

A request without an Accept-Encoding header field implies that the

user agent has no preferences regarding content-codings.  Although

this allows the server to use any content-coding in a response, it

does not imply that the user agent will be able to correctly process

all encodings. [1]

Furthermore, an empty Accept-Encoding field implies identity is the only acceptable coding...

An Accept-Encoding header field with a combined field-value that is

empty implies that the user agent does not want any content-coding in

response.  If an Accept-Encoding header field is present in a request

and none of the available representations for the response have a

content-coding that is listed as acceptable, the origin server SHOULD

send a response without any content-coding. [1]

It says nothing about being able to completely ignore the Accept-Encoding header.

So I still stand behind my statement that lifting the MUST requirement for gateway decompression doesn’t solve any of the problems.

> it's not the best for interop, but it's legal within the spec (406 might be better, but also not always great for interop).

> The "MUST decompress" effectively made gateways act as origins for certain responses,

> but they didn't have a choice about how to deal with this interop issue. By not saying anything we grant them the choice of decompressing, or sending compressed, or 406ing.

> I still definitely prefer not introducing implicit support in the first place.


[1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-5.3.4

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
Received on Saturday, 17 May 2014 18:11:17 UTC

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