Re: HTTP 2 Header Tables and Priority

On Sunday, August 4, 2013, Steve Davis wrote:

> If I understand correctly from reading -http2-04 and -compression-01, then
> the following is true:
>
> 1) There is only one set of request/response header tables per connection
> that serves all streams.
>
> 2) It is essential that the header table indexes and values are agreed by
> both peers in order to interpret and process future header frames
> correctly. i.e. The respective tables must be in the same state when
> interpreting a new header frame as it was on the peer when constructing the
> header frame.
>
> 3) However, streams can be prioritized for processing order according to
> the implementation.
>
> Given the above, there does not seem to be an ordering of header frame
> processing that will guarantee that the header tables of the connected
> peers will remain synchronized. Is this a mis-read, or a genuine issue?
>

You have to do your compression "just in time", i.e. right before you write
the frame to the network.

Note that you have to do something similar for assigning stream IDs to
guarantee monotonicity.

>
> A few smaller observations:
>
> 1) regarding -compression-01 is that substitution and increment indices
> are represented by (index + 1) to avoid collision with the literal prefix.
> Would it not be simpler, less bug-prone, and generally more consistent to
> simply define the start of the header index tables at index 1?
>
> 2) regarding -http2-04, there's a slightly inconsistent wording wrt the
> frame flag bits, e.g in section 6.2:
>
>  END_STREAM (0x1):  Bit 1 being set indicates that this frame is the
>       last that the endpoint will send for the identified stream
>
> Since bit numbering in the rest of the document number is decimal starting
> from 0, "bit 1" suggests 0x40. I am assuming 0x1 is the correct
> interpretation here which would appear in the decimal ordering as used in
> the rest of the document as "7"... minor nit-pick, I know.
>
> 3) in -compression-01 the whole idea of "integer encoding" seems
> overly-complex in order to save a few bits. Given the overall saving
> provided already by indexing, I question whether this additional saving
> really worth the effort? I guess that's a call between network saving and
> cpu savings... in this case I'd say simplicity would be more worthwhile
> than the savings for the network -- but that's just an opinion.
>
> regs,
> /s
>