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: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Thu, 18 Jul 2013 01:51:33 +0900
Message-ID: <CAPyZ6=JJONW8uciYMmApEuUaM+DQZ3PDaS7n-JaXhz7DQuytQA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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 16:52:20 UTC

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