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

Re: #578: Header Table and Static Table Indices Switched

From: Greg Wilkins <gregw@intalio.com>
Date: Wed, 1 Oct 2014 02:51:02 +1000
Message-ID: <CAH_y2NHT9s8ZqCxJd-c3Okk8w1s4FTY-ecsq4ewUg1zryrPk-g@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, Willy Tarreau <w@1wt.eu>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 1 October 2014 01:51, Jeff Pinner <jpinner@twitter.com> wrote:

> For any other headers (or these without default values), assuming they
> are repeated between messages (likely given you are precomputing their
> values as static fields), they will be inserted into the dynamic table
> and their offsets will change as more headers are added.
>
> Thus I don't see how you can realistically reuse them with a
> precomputed offset, regardless of the location of the static table.
>

Firstly I think that there is good support for adding default values for
most of the static entries, which will further improve the compression for
the low static entries.

Then headers with static names and custom values don't need to be
indexed.   For example after this change Jetty generates a date field only
once per second with a static date name index and a huffman encoded date
value.   This precomputed field is then used 10's or 100s of thousands of
times in the next second.   Previously we had to recalculate that field for
each and every connection because the date name index was different for
every connection.

Similarly for the server header, we pre-compute and can send to every new
connection because we know what the server name index will be.

 Static content in the content cache can also pregenerate last-modified and
etag headers which again will get used on lots of different connections and
don't need to be regenerated.

Previously we had pre-generated headers for http1, but were not able to add
the mechanism for h2 because every field was always custom generated for
each connection.   After this change was made we were able to generalise
pre-generation for both h1 and h2 and this is a significant saving in
scalable servers.  EVEN IF the cost was larger headers they would be
worthwhile, but the average header appears to be the same or a little
smaller.

regards












-- 
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 Tuesday, 30 September 2014 16:51:35 UTC

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