Re: Making Implicit C-E work.

On Apr 30, 2014 6:31 AM, "Roberto Peon" <grmocg@gmail.com> wrote:
>
> 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.
>

And last-modified? And, possibly, other fields from Vary? There's more
entity-specific metadata than just ETag.

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

I still think you're putting too much emphasis on C-E, particularly in
cases where it doesn't (or shouldn't) apply. What you want is compressed
data (fewer bytes) on the wire. HTTP has limited options in this regard,
and the Right Way™ (T-E) is out of the picture; but using C-E is at best a
hack, but more likely a flat out misunderstanding of its purpose. And the
current text madates, in an internet standard, that everyone support the
hack; and by extension promotes the misunderstanding.

If