Re: HTTP 2 Header Tables and Priority

Compression should always be the last step before serializing-to-the-wire
for HEADERS, else you will have problems when doing any muxing (as you've
indicated). Since HTTP/2 is currently predicated on using TCP, so long as
this rule is followed, all is well.

-=R

On Sun, Aug 4, 2013 at 6:42 PM, Steve Davis
<steven.charles.davis@gmail.com>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?
>
> 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
>