Re: Making Implicit C-E work.

I'll note that the suggested text should have said that the old
content-length and old etag MUST be removed if not replaced when doing the
decompression, but hopefully we all already knew that :)
-=R


On Tue, Apr 29, 2014 at 1:29 PM, 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.
>
> 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
>