On May 22, 2014 12:04 AM, "David Krauss" <potswa@gmail.com> wrote: > We can nip this all in the bud by limiting header block size. For header-heavy protocols, dividing the metadata stream into multiple blocks should be an essential feature in any case. Should an upper limit be set on header block size? How could it be specified? We have asked before about setting a hard limit. That doesn't work. There are too many existing uses and users that wouldn't be able to use HTTP/2 as a result. A declared maximum (i.e., settings) might work. You can't however reject a header block that you don't want. Not without also dumping the connection. Common state being what it is. The best approach is to stream headers. The HPACK design permits it, and that allows for a bounded state commitment. The only real cost is the head of line blocking. > Note, Huffman “compressed” binary data is 3.5x bigger on the wire, so 1 MiB decoded is up to 3.5 MiB transferred. I might be guessing high by many orders of magnitude, but I’m just being conservative on the side of the currently apparent design intent, which is to be unlimited. That is perhaps true if you do the naive thing, and only if you don't have any syntax constraints. The real cost depends, but if you do cookie syntax, it's closer to 1.6.
Received on Thursday, 22 May 2014 10:49:29 UTC