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: Wed, 14 May 2014 14:40:57 -0700
Message-ID: <CAEn92Trq3LW02oKiCyYCJtkSc57gGuOsrdBhs5ZF336bvJqnKw@mail.gmail.com>
To: K.Morgan@iaea.org
Cc: Matthew Kerwin <matthew@kerwin.net.au>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, C.Brunhuber@iaea.org
>
> > 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?
>

An intermediary MUST decompress payloads, as the specification says.

In the extreme hypothetical case of an intermediary which has lots of
clients which don't send a-e: gzip, and which is facing DoS at current load
levels, then passing through c-e: gzip is a non-conformant but effective
DoS mitigation which is *in-practice* unlikely to break the majority of h1
clients. Yes, this breaks spec, but if decompression DoS is an actual
concern (and with a nod to Martin's point here), it's a reasonable escape
valve.
Received on Wednesday, 14 May 2014 21:41:24 UTC

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