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

Re: Making Implicit C-E work.

From: Johnny Graettinger <jgraettinger@chromium.org>
Date: Tue, 6 May 2014 17:11:00 -0400
Message-ID: <CAEn92TqtMhhVOt0ThvLCuZEdhbi4D-9BmuoeiDbG82x6kbA0xQ@mail.gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, K.Morgan@iaea.org
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?
Received on Tuesday, 6 May 2014 21:11:36 UTC

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