W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: HTTP 2 Header Tables and Priority

From: Roberto Peon <grmocg@gmail.com>
Date: Sun, 4 Aug 2013 18:53:01 +0200
Message-ID: <CAP+FsNdDcRVxtUhN2-oJ4yvZ4Jo7H-2LJsEXg=D7pfaxaOFwqg@mail.gmail.com>
To: Steve Davis <steven.charles.davis@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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.


On Sun, Aug 4, 2013 at 6:42 PM, Steve Davis

> 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
Received on Sunday, 4 August 2013 16:53:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC