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

Re: Header compression question: duplicate header entry and current index on computing working set

From: Jeff Pinner <jpinner@twitter.com>
Date: Wed, 17 Jul 2013 10:08:15 -0700
Message-ID: <CA+pLO_i1iPWBibZZanTDMCB+TQC5xHEVUbO_ZegUWsvSb8skfQ@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Doesn't the decompressor have to sweep the table to create the new
reference set and compare the (index, name, value) entries?


On Wed, Jul 17, 2013 at 9:59 AM, Mike Bishop
<Michael.Bishop@microsoft.com>wrote:

>  How did the object get into the reference set?  Because the compressor
> referenced an object by index, or included it as a literal and added it to
> the table.****
>
> ** **
>
> So the object in the reference set points to the entry in the table it was
> added with.  If there happens to be another identical entry in the table,
> nothing says that the decompressor will even notice that.  I donít recall
> anything that requires the decompressor to sweep the header table looking
> for matches Ė thatís the compressorís job.****
>
> ** **
>
> *From:* Tatsuhiro Tsujikawa [mailto:tatsuhiro.t@gmail.com]
> *Sent:* Wednesday, July 17, 2013 9:52 AM
> *To:* Martin Thomson
> *Cc:* ietf-http-wg@w3.org
> *Subject:* Re: Header compression question: duplicate header entry and
> current index on computing working set****
>
> ** **
>
> ** **
>
> ** **
>
> On Thu, Jul 18, 2013 at 1:36 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:****
>
>  On 17 July 2013 08:56, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
> > In 3.4, to compute working set from reference set of headers, the index
> of
> > entry in header table is required.
> > The question is, when the duplicate entries are in the header table,
> which
> > index is used as the index of working set?****
>
> If, for some strange reason, a compressor created multiple identical
> entries in the table, the decompressor is required to respect that
> choice, even if it is likely to be a bug.  This prevents the
> decompressor and compressor from getting out of sync.
>
> The compressor can then reference any of the entries when using an index.*
> ***
>
>  ** **
>
> If the choice is arbitrary, then the compressor and decompressor may
> choose different index and****
>
> can get out of sync.****
>
> ** **
>
> For example,****
>
> Current header table:****
>
> |0|name1|value1|****
>
> |1|name1|value1|****
>
> ** **
>
> If name1/value1 is in reference set, compressor chooses index 0, and
> decompressor chooses index 1.****
>
> compressor wants to remove name1/value1, so reference index 0.****
>
> In decompressor side, however, seeing index header representation with
> index 0 and it is not in its reference set****
>
> (because name1/value1 is index 1), retrieve index 0 from header table and
> add it to working set.****
>
> Maybe I misunderstand the draft.****
>
> ** **
>
> If multiple identical entries are considered as a bug, then it would be
> better to****
>
> prohibit it in the spec and we are happy to not to consider these things.*
> ***
>
> ** **
>
> Best regards,****
>
> ** **
>
> Tatsuhiro Tsujikawa****
>
> ** **
>
> ** **
>
Received on Wednesday, 17 July 2013 17:08:42 UTC

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