RE: Making Implicit C-E work.

On Tuesday,06 May 2014 23:11, Johnny Graettinger wrote:

> Something that hadn't been clear to me until now (thanks Roberto) is a significant difference

> between implicit c-e: gzip and implicit t-e: gzip …

>

> Assume a gateway inter-mediating a HTTP/2 client and a HTTP/1.1 origin. When forwarding

> a POST from the client which uses c-e: gzip … it's reasonable for the gateway to forward the

> request and expect the client to know what it's doing.

>

> Conversely, when forwarding a POST from the client which uses t-e: gzip, the gateway is

> required to decompress before handing off to the origin … and face the ensuing DoS attack

> surface.



(This thread is about implicit C-E gzip for responses. C-E gzip on requests is being discussed in the thread “Support for gzip at the server #424”.  No matter though, because your example is true in the other direction as well. Plus, t-e gzip is in both directions.)



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



*I would be thrilled if a request with no ‘accept-encoding’ header implied C-E gzip, but you can opt out by explicitly sending an ‘accept-encoding’ header.*



Just as a point of clarification, I don’t think t-e gzip should be implicit.  (I may have said that in the past, but definitely changed my mind for the very reason you brought up.) I do think frame compression (t-e gzip) and its associated SETTINGS_COMPRESS_DATA setting should be enabled by default, but I think there should always be a way to opt out.



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.

Received on Wednesday, 14 May 2014 07:35:27 UTC