W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Removing dropped entry from ref set

From: Fred Akalin <akalin@google.com>
Date: Mon, 23 Sep 2013 13:51:24 -0700
Message-ID: <CANUYc_Tn9_PyZMuAvkhPL4T4jmLKo+z6Dvs4AGN3drXh5wLZ6A@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Mon, Sep 23, 2013 at 1:37 PM, Mike Bishop

>  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

>  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 .
Received on Monday, 23 September 2013 20:51:52 UTC

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