RE: HPACK

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: mardi 17 juin 2014 02:56
> To: HTTP Working Group
> Subject: Fwd: HPACK
> 
> 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.

I will add some text to better explain the design choices made here.

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

This is now correct in the latest version of the spec.

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

I added some explanation in the latest version of the spec for the Huffman table. I'll add some for the static table.

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

>From various experiments and feedback, it can be hoped that the table will not be too suboptimal. In any case, now that we have extensibility back into HTTP/2, we can define a new setting for negotiating the Huffman table to use.

Hervé

> > 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 10:28:11 UTC