RE: Making Implicit C-E work.

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?
>