- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 17 Jun 2014 10:55:36 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
More feedback from PHK, forwarded with permission. See: <https://github.com/http2/http2-spec/issues/532> Begin forwarded message: > Page 8, appending static table > ------------------------------ > > Lacking documentation, I find it somewhat dubious that > assigning higher indicies to the static tables very common > entries makes sense performance wise. > > Forcing "GET" to have an index >30 causing it to encode into two > bytes (or likely even three bytes) rather than one seems very > counter inuitive. > > The dynmic and shifting indicies for the static table also robs > high-performance load balancers an important optimization opportunity > (ie: screening out non-GETs and similar). > > The optimal case is probably to have a small static table > at the front and another one with less used entries at the > tail, but I doubt that complexity is warranted. I would just > put the static table at the front. > > > Page 25, just before the table > ------------------------------ > > As an example, the Huffman code for the symbol 48 (corresponding to > the ASCII character "0") consists in the 5 bits "0", "0", "1", "0", > "1". This corresponds to the value 5 encoded on 5 bits. > > This does not match the table. > > Page 25, the table(s) > --------------------- > > The RFC should document for the future where these tables came from, > people are (rightfully) quite paranoid about "magic numbers appearing > out of nowhere" these days. > > It might be wise to reserve a couple of bits somewhere to allow the > tables to be revised if experience shows them to be too suboptimal. > > Why does it make sense to assign huffman codes to characters which > are illegal in HTTP headers, such as 0x01-0x31 and which should cause > errors if encountered ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 17 June 2014 00:56:04 UTC