Re:HPACK: the silent killer (feature) of HTTP/2
by byuu on Monday November 28, 2016 @03:59PM
(#13058348)
> Many of your responses should be "304 Not Modified", in which case you don't send anything back but the headers.
A 304 should be able to fit into a single frame, unless you're doing things very wrong. You don't even need headers in that case.
> In addition, hpack also allows the client to compress their request headers, which decreases your incoming traffic.
Yeah, that was the DoS concern I had. Lots of web server software checks the incoming header sizes don't exceed a certain length. But with huffman expansion, you can't quite make an INFLATE bomb, but if the implementation doesn't have a backout function during the decompression, you could consume a huge amount of memory by abusing this.
> ideally, only the path will change between requests.
Can you put the path at the bottom of an HTTP/2 request? Otherwise it would be tricky with lots of bit-shifting to reuse existing compressed headers but insert new paths onto the top of each one.
A 304 should be able to fit into a single frame, unless you're doing things very wrong. You don't even need headers in that case.
> In addition, hpack also allows the client to compress their request headers, which decreases your incoming traffic.
Yeah, that was the DoS concern I had. Lots of web server software checks the incoming header sizes don't exceed a certain length. But with huffman expansion, you can't quite make an INFLATE bomb, but if the implementation doesn't have a backout function during the decompression, you could consume a huge amount of memory by abusing this.
> ideally, only the path will change between requests.
Can you put the path at the bottom of an HTTP/2 request? Otherwise it would be tricky with lots of bit-shifting to reuse existing compressed headers but insert new paths onto the top of each one.