RE: Making Implicit C-E work.

Maybe someone needs to use small words or something, but to me, this DoS
claim is this far poorly supported in fact from my reading.

Assuming that you employ flow control, the only commitment an intermediary
makes when decompressing is the decompression context for each stream. That
is bounded in size too. That might be larger than people might like, but
I'm not all that excited about a new protocol that is more expensive to
operate than an old one in some corner case.
On May 14, 2014 1:37 PM, <K.Morgan@iaea.org> wrote:

> On 14 May 2014 17:52, jgraettinger@google.com wrote:
> > On 14 May 2014, Keith Morgan wrote:
> >> Nearly all of the problems brought up w.r.t. t-e gzip are also true for
> C-E
> >> gzip. This one is no exception.
> >> Implicit C-E gzip adds a large DoS attack surface to intermediaries.
> >> An attacker simply sends requests without ‘accept-encoding: gzip’ from
> a HTTP/1.1.
> >> origin through a 1.1<->2 gateway for a resource it knows the server will
> >> implicitly C-E gzip. Then (using your own words Johnny) “the gateway is
> required
> >> to decompress before handing off to the origin … and face the ensuing
> DoS attack
> >> surface.”
> >
> >
> > This is a problem which already exists today. As Roberto noted, existing
> h1
> > intermediaries add a-e: identity on behalf of clients who didn't ask for
> it, and
> > existing servers send c-e: gzip anyway, because the observed impact of
> not
> > compressing is higher than the interop issues it introduces.
> >
> >
> > The DOS mitigation which is available today, and continues to be
> available for
> > h2/h1 gateways under implicit c-e: gzip, is to pass through what the
> server sent
> > without decompression. There's a high likelihood the h1 client will be
> able to
> > handle c-e: gzip  (and even prefers it), which is definitely not true if
> t-e: gzip
> > were used instead.
>
>
> The current -12 spec says "Intermediaries that perform translation from
> HTTP/2 to
> HTTP/1.1 MUST decompress payloads unless the request includes an
> Accept-Encoding
> value that includes 'gzip'." [1].
>
> So implicit gzip either introduces a legitimate DoS at the HTTP/2 to
> HTTP/1.1 gateway
> or you want gateways to ignore this requirement and introduce interop
> issues. Which
> is it?
>
> If it's the latter (forward compressed regardless of the A-E header), then
> what's the
> point of Roberto's "uncompressed-*" headers for the gateways if you don't
> really want
> the gateways to deccompress? And what's the point of this "MUST decompress
> payloads"
> requirement?
>
> If it's the former (decompress at the gateway), and you want to live with
> the DoS
> attack surface, I have to ask again, what's the point of all this - just
> to have
> compression on one or two h2 hops and then force gateways to dynamically
> decompress??
>
>
> [1] http://http2.github.io/http2-spec/#Compression
> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.
>
>