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> wrote:

> In message <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         | 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>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.