Re: Making Implicit C-E work.

For better or worse, C-E is what is deployed today. Many of my customers
will not be writing custom servers, and as such to be deployable, we need
solutions that will work with what is out there.
Otherwise, the feature is effectively only of theoretical use for the
majority of customers.

I don't dispute that one could use T-E over HTTP/2 for this, assuming that
it was end-to-end (which, unfortunately, it will not be for quite some
time).
-=R


On Tue, Apr 29, 2014 at 2:25 PM, Matthew Kerwin <matthew@kerwin.net.au>wrote:

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