Subject: Re: Header compression question

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Jul 2013 15:10:19 +1000

On 01/07/2013, at 5:20 AM, Gábor Molnár <[email-masked]> wrote:

> PS: should I send messages like this to the editors of the spec only or is it OK to send this to the list?

To the list, please.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: RUELLAN Herve <[email-masked]>
Date: Tue, 2 Jul 2013 08:18:28 +0000

Your understanding is correct: the working set may shadow entries in the header table. However, it should not be a problem.
When starting the processing (encoding or decoding) of a new set of headers, the working set and header table are in sync.
They can go out of sync if a header is encoded as a literal representation and replaces an existing entry of the header table. The updated entry in the table is no more accessible through its index, however, it has already been added to the working set: there is no need to access it through its index for this current set of headers.

There is one corner case that may pose a problem: this is when the exact same header is repeated twice in the same set.

Hervé.

> -----Original Message-----
> From: Gábor Molnár [mailto:[email-masked]]
> Sent: dimanche 30 juin 2013 21:20
> To: HTTP Working Group
> Subject: Header compression question
> 
> When implementing the differential coding part of the header compression
> spec, the following question came up.
> 
> If I understand it correctly,
> 1. the indexes in the working set are frozen at the beginning of the decoding
> process, so they might go out of sync with the header table 2. when
> dereferencing an index, the working set is checked first and then the header
> table 3. as a result of the combination of these, the working set may shadow
> entries in the header table, and make them unaccessible
> 
> Is this the way dereferencing indexes work, and this "shadowing" must be
> worked around when doing the encoding part, or did I misunderstand
> something?
> 
> 
> Thanks,
>   Gábor

---

From: Gábor Molnár <[email-masked]>
Date: Tue, 02 Jul 2013 14:45:34 +0200

Thanks for the clarification!

I see one more interesting case, that is somewhat more probable. The header
table and the
working set may become out of sync also when dropping entries from the
beginning of the
header table because of the size limitation. Renumbering happens, and some
entry in the
working set may shadow entries that are not related to them.

#  HT  WS          #  HT  WS
---------          ---------
1  A               1  B              Referencing C and E
2  B   B     =>    2  C   B     =>   is not possible
3  C               3  D
4  D   D           4  E   D

However, I don't see this as a big problem as far as the implementation
counts with this.

  Gábor

2013/7/2 RUELLAN Herve <[email-masked]>

> Your understanding is correct: the working set may shadow entries in the
> header table. However, it should not be a problem.
> When starting the processing (encoding or decoding) of a new set of
> headers, the working set and header table are in sync.
> They can go out of sync if a header is encoded as a literal representation
> and replaces an existing entry of the header table. The updated entry in
> the table is no more accessible through its index, however, it has already
> been added to the working set: there is no need to access it through its
> index for this current set of headers.
>
> There is one corner case that may pose a problem: this is when the exact
> same header is repeated twice in the same set.
>
> Hervé.
>
> > PS: should I send messages like this to the editors of the spec only or
> is it OK
> > to send this to the list?
> >
> >
> > Thanks,
> >
> >   Gábor
> >
>
>

---

From: RUELLAN Herve <[email-masked]>
Date: Tue, 2 Jul 2013 12:53:21 +0000

Yes, this is another edge case. 

I'll be adding some warning for implementers in the spec.

Hervé.

> Sent: mardi 2 juillet 2013 14:46
> To: RUELLAN Herve
> Cc: HTTP Working Group
> Subject: Re: Header compression question
> 
> I see one more interesting case, that is somewhat more probable. The
> header table and the
> 
> header table because of the size limitation. Renumbering happens, and
> some entry in the
> 
> 	Your understanding is correct: the working set may shadow entries in
> the header table. However, it should not be a problem.
> 	They can go out of sync if a header is encoded as a literal
> representation and replaces an existing entry of the header table. The
> updated entry in the table is no more accessible through its index, however,
> it has already been added to the working set: there is no need to access it
> through its index for this current set of headers.
> 
> 	There is one corner case that may pose a problem: this is when the
> exact same header is repeated twice in the same set.
> 
> 	Hervé.
> 
> 
> 	> PS: should I send messages like this to the editors of the spec only
> or is it OK