RE: Header compression question

Yes, this is another edge case. 

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

Hervé.

> -----Original Message-----
> From: Gábor Molnár [mailto:gabor.molnar@sch.bme.hu]
> Sent: mardi 2 juillet 2013 14:46
> To: RUELLAN Herve
> Cc: HTTP Working Group
> Subject: 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
>  >
> 
> 
>

Received on Tuesday, 2 July 2013 12:53:56 UTC