Re: Header compression question

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 <Herve.Ruellan@crf.canon.fr>

> 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:gabor.molnar@sch.bme.hu]
> > 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?
> >
> >
> > 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
> >
>
>