Re: Making Implicit C-E work.

Something that hadn't been clear to me until now (thanks Roberto) is a
significant difference between implicit c-e: gzip and implicit t-e: gzip,
on the upload path from the client. This has been referenced on the list
already, but I benefited from having it explicitly unpacked, and others may
as well:

Assume a gateway inter-mediating a HTTP/2 client and a HTTP/1.1 origin.
When forwarding a POST from the client which uses c-e: gzip, the gateway is
pragmatically able to forward that request wholesale to the origin. While
not universal, many 1.1 servers support c-e: gzip POSTs today (eg, Apache's
mod_deflate). At worst, handling an unexpected Content-Encoding is not a
new problem for 1.1 origins. Thus it's reasonable for the gateway to
forward the request and expect the client to know what it's doing.

Conversely, when forwarding a POST from the client which uses t-e: gzip,
the gateway is *required* to decompress before handing off to the origin
(given the nonexistent HTTP/1.1 support for t-e: gzip), and face the
ensuing DoS attack surface. Either that, or switch to c-e: gzip :)


On Sat, May 3, 2014 at 1:57 AM, Matthew Kerwin <matthew@kerwin.net.au>wrote:

> On May 3, 2014 8:31 AM, "Roberto Peon" <grmocg@gmail.com> wrote:
> >
> >> - Matthew wrote: "[What about] last-modified? And, possibly, other
> fields from Vary? There's more entity-specific metadata than just ETag."
> >>
> >
> > The rule is simple ":uncomressed-foo" replaces "foo" if decompression is
> done.
> >
>
> Ohh, is this a header pattern? As in, all headers that start with
> ":uncompressed-" (or whatever) get copied across at the gateway?
>
> So you're effectively sending two complete sets of headers, and optimising
> for the overlap.
>
> I can live with this idea, as long as it's made really clear which header
> is used by caches and origins for supporting conditionals and ranges in
> which situations.
>
>
> >>
> >> - Matthew also wrote: "Cache-Control:no-transform explicitly forbids
> the proxy from altering the representation. It's not allowed to decompress
> it."
> >
> > I've addressed this. It isn't altering the representation if it is
> effectively transmitting both.
> >
>
> Yeah, I understand this now; you've theoretically transmitted the
> uncompressed entity and all its headers, and the compressed one and all of
> its. Two tiers of encoding. And because you can detect support for c-e, you
> can choose to only use one or the other, if you want.
>
> It's a pretty conceptually rich change; I'd imagine not a great deal of
> code would change, but I think it needs a bit more thinking and discussion
> to make sure we end up with something that works properly and doesn't hide
> other problems.  Are people happy to invest time into something like this?
>