- From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
- Date: Tue, 2 Jul 2013 08:18:28 +0000
- To: Gábor Molnár <gabor.molnar@sch.bme.hu>, "HTTP Working Group" <ietf-http-wg@w3.org>
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 08:19:05 UTC