Making Implicit C-E work.

Here is a proposal for keeping implicit C-E around safely.

When gzip is not in the accept-encoding, gzip is assumed to be implicitly
accepted, as opposed to explicitly accepted. This means that servers/client
which wish to indicate that it is explicitly accepted do put a-e: gzip in
the headers.

Servers seeing an implicit gzip a-e and sending a compressed entity MAY
include an additional header field, ":uncompressed-etag". An HTTP2 ->
HTTP/1 gateway which is decompressing and forwarding an entity MUST replace
ETAG with the value of this header, if it exists, or insert it if it does
not.

Additionally, to address the deployment fact that there are non-browser
usecases out there which are stuck using HTTP/1.1 servers and clients,
which only accept chunked-encoded messages with the headers include
content-length:

Servers or Clients seeing an implicit gzip a-e and sending a compressed
entity MAY include an additional header field,
":uncompressed-content-length", which contains the uncompressed content
length. An HTTP2 -> HTTP/1 gateway which is decompressing and forwarding an
entity MUST replace content-length with the value of this header, if it
exists, or insert it if it does not.


I know for a fact that compression in the client->server direction is
desirable *and* is likely to be used for non-browser usecases, and so I
think both of these end up being useful given that there is no (useful,
non-latency harming) negotiation for accepting compressed entities in the
client->server direction for HTTP/1.

-=R