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