HTTP 2 Header Tables and Priority

[Steve Davis <[e-mail]>]

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?

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