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

RE: Header Compression Overview

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Thu, 4 Jul 2013 13:23:34 +0000
To: James M Snell <jasnell@gmail.com>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
CC: Mike Bishop <Michael.Bishop@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E525EE3F7F@ADELE.crf.canon.fr>

> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: mardi 2 juillet 2013 19:25
> To: Ilari Liusvaara
> Cc: RUELLAN Herve; Mike Bishop; ietf-http-wg@w3.org
> Subject: Re: Header Compression Overview

> >
> > Also, there is no operation that could be used to "refresh" header
> > table entries without explicitly coding for value? Since some headers
> > could be quite expensive to code (that one WAP-related header
> > anyone?), one would want to keep those live...
> >
> Nope, there is no "touch" operation that just keeps the header table entry
> alive without using it. Adding such a thing would just add unnecessary
> complexity, I think.

Even using a table entry will not keep it "alive": the eviction mechanism doesn't take into account the "freshness" of the entries.
The intended usage of the header table is to use substitution indexing to replace old headers by new headers once the table is full. In this way, the encoder has a full control on which headers are kept in the table and which are removed.
The eviction mechanism mainly serve two purposes:
- Reducing the whole header table size if the receiver request it (this is not possible yet in the current HTTP/2.0 draft).
- Handling fragmentation of the header table. It the header table is full of very small entries, then substitution alone doesn't allow to replace a bunch of them with a longer entry. With the eviction mechanism, a large header can replace a small one, with a side effect of dropping other headers through the eviction mechanism.

Received on Thursday, 4 July 2013 13:24:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC