Re: Making Implicit C-E work.

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