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: Willy Tarreau <w@1wt.eu>
Date: Wed, 16 Jul 2014 08:18:44 +0200
To: Greg Wilkins <gregw@intalio.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20140716061843.GF14304@1wt.eu>
On Wed, Jul 16, 2014 at 08:08:25AM +0200, Willy Tarreau wrote:
> On Wed, Jul 16, 2014 at 04:00:33PM +1000, Greg Wilkins wrote:
> > 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.
> 
> I mean, the current design allows you to have a header field whose value
> changes between consecutive requests (eg: a proxy aggregating multiple
> users' requests), and still have that changing value referenced with
> little overhead. Here to achieve the same result we'll need to have
> that header field present in the static table in order for the index to
> fit in a 6-bit quantity. I *think* that we have most common fields in the
> static table so that should not be an issue. But that's something we might
> want to double-check. Note that I'm clearly speaking about changing a
> header value, not reusing the same value (which needs only one byte for
> all cases).

After checking in a number of traces, the only field I'm seeing subject to
changing between requests is x-forwarded-for, and that's clearly one which
is sent where we don't care about saving one byte per request over the wire.
So your proposal might be reasonably efficient.

Regards,
Willy
Received on Wednesday, 16 July 2014 06:19:09 UTC

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