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

Re: Call for Consensus: Remove "reference set" from HPACK (to address #552)

From: Greg Wilkins <gregw@intalio.com>
Date: Wed, 16 Jul 2014 16:00:33 +1000
Message-ID: <CAH_y2NEr6SooCDT+N_8WkbS2v9SiDyQsmkkMqUOv3oPO0H9gGQ@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 16 July 2014 15:45, Willy Tarreau <w@1wt.eu> wrote:

> The problem I'm seeing with this change is that you need one extra-byte to
> send litteral headers fields that are not present in the static table.

The first 64 entries can still be sent with 1 byte.   So I think in many
common use-cases almost all the indexes will just be 1 byte.

> Maybe
> on the other hand it rarely happens that they're not in the static table ?

Well the static table has few name+value fields, but the ones it does have
are common.

> It may be nice to re-run a check if we change that to see if the static
> table
> is still optimal then, because before this change, it's only used as a
> fallback to look up common values. Now we want it to be used for almost
> all litteral lookups, and we might want to add one or two fields there
> if we realize that a common one is missing.

I don't think it is correct to say for 'almost all literal lookups'.   Any
field with a custom value (with or without an indexed name) will be put
into the header table.  The first 64 of those (ie the last 64) will be
indexed with a single byte.   You only need go to a 2 byte index if the
header table is large enough to hold more than 64 entries and your entry
was added more that 64 additions ago.    I think 2 byte indexes are going
to be rare.


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.
Received on Wednesday, 16 July 2014 06:01:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC