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

Re: Making Implicit C-E work.

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 19 May 2014 10:47:33 +1000
Cc: Matthew Kerwin <matthew@kerwin.net.au>, HTTP Working Group <ietf-http-wg@w3.org>, C.Brunhuber@iaea.org, grmocg@gmail.com, K.Morgan@iaea.org, jgraettinger@chromium.org
Message-Id: <D98907D3-A537-40AE-8689-87D9D34DDA69@mnot.net>
To: Martin Thomson <martin.thomson@gmail.com>
Right. We’re not saying that this solves the issue at hand — only that it improves the spec to downgrade this requirement.


On 19 May 2014, at 9:18 am, Martin Thomson <martin.thomson@gmail.com> wrote:

> Yes, I think that Matthew's analysis is correct. It is probably not ideal, but th is seems like a case where server (out really intermediary) discretion wins out. We might speculate that this is intended to provide an escape hatch for over constrained scenarios. Perhaps we've just created another such scenario.
> On May 18, 2014 5:53 PM, "Matthew Kerwin" <matthew@kerwin.net.au> wrote:
> On May 18, 2014 4:10 AM, <K.Morgan@iaea.org> wrote:
> >
> > > ... 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]
> >  
> This. The only normative language in the whole thing, and it's a SHOULD. "If you can't serve what the client wants, you should serve it uncoded, but we're cool for you to second-guess the protocol if called for by circumstances." (Amusingly it doesn't say that you should send an acceptable representation if you have one.)
> At the boundary between 1.1 and 2, the gateway either acts as a proxy (by not transforming), or an origin. If it acts as an origin it already inherits the requirements you referenced. Saying "MUST decompress" means the gateway must act as a second-class origin -- it can't choose to be a proxy, but it doesn't get the same SHOULD options as any other origin.
> > So I still stand behind my statement that lifting the MUST requirement for gateway decompression doesn’t solve any of the problems.
> >
> Except for the MUST decompress/MUST NOT transform issue, which was my big sticker.
> Stepping back to the roots: jerk proxies hurt performance by altering a-e headers, and capitalist servers hurt interop by ignoring them.
> If we keep the "MUST support gzip" directive then new (h2) proxies lose the motivation to be jerks. Then, if we let gateways do what they like, they get to choose on a case-by-case basis whether the jerks or the capitalists win, on the 1.1 side of the gateway. In that case I prefer to let market forces and/or experience drive the decision, rather than our assumptions here; and as (I think) I said before, it's much easier to update proxy config than roll out a new protocol. Thus, non prescriptive language is to be preferred.
> Roberto, you said that interop issues came up as a result of servers assuming a-e:gzip; can you tell us what they actually were? Would it hurt the existing (1.1) web if they kept happening? And by extension, would they hurt the h2 web if they carried over?

Mark Nottingham   http://www.mnot.net/
Received on Monday, 19 May 2014 00:47:58 UTC

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