W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Making Implicit C-E work.

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 29 Apr 2014 13:30:58 -0700
Message-ID: <CAP+FsNcrMNBseh5qjEy4P6-NozBB7bqbEZgCy5mR3rC3KDmX9w@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
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
>
Received on Tuesday, 29 April 2014 20:31:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC