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

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

From: Jeff Pinner <jpinner@twitter.com>
Date: Tue, 30 Sep 2014 15:55:00 -0700
Message-ID: <CA+pLO_hkmE5egoOCHzMvHGnvxNNVEt=TU6ceaXqOTD1q8UFWzg@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.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>
> 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.

This isn't a compelling argument to me.

Without indexing, you can still re-use the huffman encoded data value
regardless of where the static table is.

And if you do index, to say share this value between responses on the
same HTTP/2 connection, then you have to lookup the offset even if the
static table comes first.

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

Again here, you can none of the benefit of sharing the value amongst
multiple responses on the same connection. You are trading off
compression efficiency for not having to do a index lookup.

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

So the TL;DR here seems to be you're not using indexing.

My response is to use indexing, it has low computational overhead and
you get much higher compression efficiency reusing these values.
Received on Tuesday, 30 September 2014 22:55:26 UTC

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