Re: Making Implicit C-E work.

On 29.04.2014 22:29, Roberto Peon 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.
>
I think to make this work the MAY is not enough, e.g. it should be along 
the line of servers seeing an implicit gzip a-e and sending a compressed 
entity with an ETag header MUST include an additional header field, 
":uncompressed-etag". Don't think you can enforce such a thing however. 
For example PHP doesn't support you with 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.
>
> -=R
Adding the compression support on the transport level allows web servers 
to compress content which would otherwise be send uncompressed. Btw. 
making the A-E gzip implizit disables C-E gzip in current environments 
like PHP. I guess this can be repaired quite easily, but you need a 
HTTP2 aware version.

Received on Wednesday, 30 April 2014 08:16:04 UTC