Re: Making Implicit C-E work.

On 14.05.2014 17:52, Johnny Graettinger 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.
I have seen adding a-e added to a proxy because nobody knowing about the 
interop issue and I have seen it removed after years.

> 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.
>
In h1 the use of compression is negotiated and the server will not send 
compressed content when the client can't handle it. With implicit c-e: 
gzip this is changed and this disables this DOS mitigation or make 
suddenly a number of h1 clients incompatible.

Regards,
Roland