Re: Making Implicit C-E work.

>
> > 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.