- From: Andrew Rockwell <andrero@microsoft.com>
- Date: Mon, 23 Sep 2013 20:51:11 +0000
- To: Mike Bishop <Michael.Bishop@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <eb47ba4cf9394cd582e1d7a3b4079501@BN1PR03MB220.namprd03.prod.outlook.com>
Roberto clarified this a while ago: “Any removal from the state set requires that anything that pointed to it be removed (else you'd segv or equivalent). Thus, substitution or expiry always requires the corresponding reference-set entry to be removed.” There’s a GitHub issue open tracking its inclusion into the spec, though it hasn’t seen any love in a bit: https://github.com/http2/http2-spec/issues/238 Andrew From: Mike Bishop [mailto:Michael.Bishop@microsoft.com] Sent: Monday, September 23, 2013 1:37 PM To: ietf-http-wg@w3.org Subject: Removing dropped entry from ref set 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. 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. Am I missing something simple here? Sent from Windows Mail
Received on Monday, 23 September 2013 20:51:56 UTC