Re: #445: Transfer-codings

Apologies for replying to myself.

tl;dr: I'm happy to drop transport-level encoding for HTTP/2 as long as
HTTP/3 picks it up straight away, and as long as the transition to HTTP/2
makes the future transition to HTTP/3 much easier.

On Apr 5, 2014 4:42 AM, "Matthew Kerwin" <matthew@kerwin.net.au> wrote:
>
> The current semantics of HTTP force this type of compression (i.e. not at
the 'entity' level) to be at the transport level, and thus hop-by-hop.

I've had a thought (note that it's a 5am thought, after waking up at 3:30
for no good reason): introduce, outside of HTTP/2, a new semantic layer,
below the entity but above transport. Call it end-to-end transport.

It would include new headers for negotiating compression, almost exactly
like TE and Transfer-Encoding, except that the encoding can only be applied
by the origin. It would also introduce a new response header
"Transfer-Length" which holds the length of the _encoded_ payload.

Intermediaries could alter the headings the usual ways (stripping things
from TE; maybe adding things to TE as long as they decode before
retransmitting). Just not ever *encoding*.

Entity-specific metadata (e.g. ETag, Content-Length) and operations (e.g.
Range) are not affected by the encoding. I'm not sure, but I think it
doesn't affect Vary either.

For example, a client may request the range bytes 1024 to 2045 and receive
a 206 with Content-Length 1024, but a Transfer-Length of 300 and 300 bytes
of gzip'd data which, unzipped, holds the full KB range.

Since this is one of those things where participants have to explicitly opt
out (a caching proxy that ignores and forwards these headers will get
confused) I guess this is an idea to hold over for HTTP/3.

If we think that it will be relatively easy to get /3 going once /2 is out,
I'd be happy to put this entire discussion on hold until then, as long as
we're sure to address it soon.