- From: Fred Akalin <akalin@google.com>
- Date: Mon, 23 Sep 2013 13:51:24 -0700
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CANUYc_Tn9_PyZMuAvkhPL4T4jmLKo+z6Dvs4AGN3drXh5wLZ6A@mail.gmail.com>
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 .
Received on Monday, 23 September 2013 20:51:52 UTC