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

Re: Header Table and Static Table Indicies Switched

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 07 Aug 2014 04:36:07 +1200
Message-ID: <53E25977.3000900@treenet.co.nz>
To: ietf-http-wg@w3.org
On 7/08/2014 3:07 a.m., Jeff Pinner wrote:
>> There is also another good benefit for encoding with static indexes low.
>> Because the index does not change for fields like Date and Server, you can
>> every second pre-encode the bytes for fields like:
>>   server: jetty-9.3.0
>>   date: Wed, 06 Aug 2014 05:19:19 GMT
>> With the static index's low, this pre-encoded value is the same for all
>> connection, as it is not a function of the size of the dynamic table of each
>> connection.   Thus the same pre-encoded value may be used 10s of thousands
>> of times, rather than encoding these fields on each and every response for
>> each and every connection.
>> cheers
> you still pre-encode the huffman strings
> are you talking about pre-encoding the index for "date" to 33 instead
> of 33 + headerTable.length() ?
> if so, i'd argue that the pre-encoded huffman buys you way more than
> the bit of arithmetic before you copy into the send buffer and doing
> the addition is well worth the tradeoff

Every table entry could have a huffman pre-encoded for its index number
and just dump that out.

The same optimization can be applied to both header orderings and the
remaining problem in that particuular calculation is the repeated acts
of addition when static follows dynamic.

Also, don't forget the effected context. When inserting/deleting into
dynamic table all the static entries have to be re-indexed on top of any
later dynamic entries. All unnecessary work when static comes first.

Received on Wednesday, 6 August 2014 16:36:42 UTC

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