RE: Making Implicit C-E work.

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?