Re: Removing dropped entry from ref set

2013/9/24 Mike Bishop <Michael.Bishop@microsoft.com>

>  Yes, that’s a reasonable interpretation.  While the spec could be
> clearer, I think that’s the correct reading.  That still leaves open the
> question about correct behavior, though.  You said “You'll need to take the
> appropriate action when an entry in the reference set gets dropped, which
> is most likely explicitly emitting it before it gets dropped.”  Is this
> appropriate action on the part of the compressor, or the decompressor?
>
>  If the compressor, what action is that -- does it need to notice that an
> entry it cares about is going to be dropped and immediately encode two
> indexed references to it, forcing it to be emitted before it’s dropped?  Or
> is it an appropriate action on the decompressor’s part, which means the
> compressor needs to ensure that nothing in the reference set it wishes to
> remove falls off the list before it gets removed?
>

That is the responsibility of the encoder. I would recommend having a look
at Tatsuhiro's encoder algorithm which deals with these corner cases
correctly:
http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/1135.html


>
>  Sent from Windows Mail
>
>   *From:* Fred Akalin <akalin@google.com>
> *Sent:* ‎Monday‎, ‎September‎ ‎23‎, ‎2013 ‎1‎:‎51‎ ‎PM
> *To:* Mike Bishop <Michael.Bishop@microsoft.com>
> *Cc:* ietf-http-wg@w3.org
>
>   On Mon, Sep 23, 2013 at 1:37 PM, Mike Bishop <
> Michael.Bishop@microsoft.com> wrote:
>
>>  Found a corner case that I’m not sure HPACK handles, or if it does I’m
>> not finding it and we might want to clarify….
>>
>>  Sequence of events:
>>
>>    - Header X is present in reference set and header table.
>>    - Some other addition to the header table causes header X to be
>>    dropped.  (This could be a header that causes X to be dropped, or a
>>    substitution operation that replaces X.)
>>
>>
>>    - Now the compressor wishes to remove X from the reference set.  How
>>    does it do so?
>>
>>
>>  Per 3.2.1, the only operation that has the effect of removing an entry
>> from the reference set is an indexed representation of a header already in
>> the reference set.  But you can’t send the indexed representation of a
>> header no longer in the header table.
>>
>
>  >From 3.1.3: "A reference set is defined as an unordered set of
> references to entries of the header table." I interpret this to mean that
> when an entry is removed from the header table, it's removed from the
> reference set also.
>
>
>>   To address it, we could say:
>>
>>    -  *Replacing X with another entry in the header table also replaces
>>    X in the reference set.*  This makes perfect sense, but needs to be
>>    stated.
>>    -  *Dropping X from the header table also drops it from the reference
>>    set.*  This is more problematic, because the compressor can’t just
>>    pass over headers it wants to communicate which are already in the
>>    reference set.  Instead, it needs to leave them until the end, then check
>>    if they’re all still in the reference set.  If not, it needs to take
>>    another action to emit one or more, then check that all the remaining are
>>    still in the reference set…  This loops until the entire remaining set is
>>    still present.
>>
>>
>  You'll need to take the appropriate action when an entry in the
> reference set gets dropped, which is most likely explicitly emitting it
> before it gets dropped. I ran into this same problem, which Tatsuhiro
> Tsujikawa pointed out: see
> https://github.com/akalin-chromium/httpbis-header-compression/issues/1 .
>