RE: HPACK

They previously were at the beginning, and were moved to the end for a couple of reasons:

·         Having the static table first means that the headers you add are always two bytes to reference instead of one.  An extra byte per indexed header on both add and remove adds up, and analysis of header sets showed that compressor-added entries were referenced more often than entries from the static table.

·         To partially mitigate that, client and server had separate (shorter) static tables; unifying them (since at the end, total length of the static table matters less) reduced complexity.

The copying is there because otherwise, the reference set would include things in the static table.  There was a push for operation to be totally stateless with a context size of zero, which it’s not if you have to track the reference set between requests even without a header table.  (Alternately, you could say that referencing something in the static table doesn’t add it to the reference set, but then you’re forking the semantics of the two tables even further, and the most common headers have to be re-sent every time.)

Requiring headers to be “first” when they’re in the reference set gets interesting.  Your suggestion of having two rounds of reference set emissions is a possible way around that, but requires the decoder to have additional knowledge of the header contents.  Currently, it doesn’t actually know anything about headers, just key-value pairs where both key and value are a series of octets.

I’m certainly not going to argue that what we have is perfect, but I will argue that we previously had some of what’s being proposed, and we moved away from it based on data and the consensus of implementers.  Has new data and implementation experience arisen to suggest we made an error, and is the error of a sufficient magnitude that it’s worth blowing out the schedule?

If not, an extension that always encodes the routing headers as literals and places them first might be an interesting experiment….  ☺

From: Greg Wilkins [mailto:gregw@intalio.com]
Sent: Wednesday, June 18, 2014 5:10 AM
To: HTTP Working Group
Cc: Poul-Henning Kamp
Subject: Re: HPACK


I'm totally on board with having the static table at fixed index's below the dynamic table.  I would also like to avoid the need to copy static entries from the static table to the dynamic table in order to use them!
But we can't require that the first few fields are :scheme etc. because the intention is that most of those common unchanging fields will end up in the reference set and not be sent at all.  ie, there is no need to send :scheme or :authority on every request. :method will mostly be GET or POST and only occasionally  switch.  Path and query will mostly be sent, so perhaps they can be first encoded.
Perhaps we can insist that all : headers are sent first and that at the first non : header, we can then emit all : headers from the refset.
But if we are going to consider such significant changes, then I would change a lot more about hpack.

cheers

On 18 June 2014 11:52, Poul-Henning Kamp <phk@phk.freebsd.dk<mailto:phk@phk.freebsd.dk>> wrote:
In message <6C71876BDCCD01488E70A2399529D5E532D72B36@ADELE.crf.canon.fr<mailto:6C71876BDCCD01488E70A2399529D5E532D72B36@ADELE.crf.canon.fr>>, RUELL
AN Herve writes:

>I will add some text to better explain the design choices made here.
Adding some restrictions which closely mirror similar restrictions
in HTTP/1.1, will make it much easier to do high-speed "triage"
processing of HTTP/2.0.

I would allocate a few constant low indices to the values which
represent the majority of "trivial" traffic:

        1       :method         GET
        2       :scheme         http
        3       :status         200
        4       :status         304
        5       :authority
        6       :path
        7       :query

and I would mandata that a request always provide the following
fields in this exact order, as the first fields in HEADER(...):

        :scheme
        :method
        :authority
        :path
        :query

and that responses always have the :status as the first field.

My finger in the air estimate that this reduces the processing
requirement for the "is this a trivial case" decision by about
a factor of ten.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG<mailto: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.



--
Greg Wilkins <gregw@intalio.com<mailto:gregw@intalio.com>>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.