What Johnny said. I also note the possibility of just dropping things on the floor, which is the ultimate end state in successful DoS attacks. I'd be concerned if the commitment were unbounded in some way (other than time, which is manageable), but I haven't seen any claim to that effect. On May 14, 2014 2:43 PM, "Johnny Graettinger" <jgraettinger@chromium.org> wrote: > > 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:58:51 UTC