- From: Roberto Peon <grmocg@gmail.com>
- Date: Tue, 2 Jul 2013 15:52:01 -0700
- To: James M Snell <jasnell@gmail.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNfTKafw8U1i+qof4kdkpnZ2i05rQan4UoDgLgMidaf2PQ@mail.gmail.com>
yup. That'd mean you couldn't insert that in substitution mode, which seems fine. -=R On Tue, Jul 2, 2013 at 3:50 PM, James M Snell <jasnell@gmail.com> wrote: > On Tue, Jul 2, 2013 at 3:11 PM, Roberto Peon <grmocg@gmail.com> wrote: > > It should be before as this guarantees that the maximum memory size is > not > > exceeded. > > The other approach offers no such guarantee, and becomes an interesting > > attack vector. > > Well, I agree but... just teasing out edge cases while I write up unit > tests... Consider a simplistic example: > > Header Table, Max size = 15 > > 1 A = B > 2 C = D > 3 E = F > 4 G = H > 5 I = J > > Substitute #5 with FOOBARBAZ = 123456 > > If we reserve before... items 1-5 to be removed and the table to be > emptied... Then we attempt to do the substitution, index #5 no longer > exists... In the previous question, we already established that > attempting to substitute an index that currently does not exist should > result in an error. > > - James > > > > > -=R > > > > > > On Tue, Jul 2, 2013 at 3:05 PM, James M Snell <jasnell@gmail.com> wrote: > >> > >> Also... > >> > >> 4. On the eviction strategy... The spec currently states: "When an > >> entry is added to the header table, if the header table size is > >> greater than the limit, the table size is reduced by dropping the > >> entries at the beginning of the table until the header table size > >> becomes lower than or equal to the limit. Dropping entries from the > >> beginning of the table causes a renumbering of the remaining entries." > >> > >> Does the size check and adjustment occur BEFORE or AFTER adding the > >> new entry to the table? The difference is critical for proper > >> implementation of the Indexing with Substitution case. Example: > >> > >> Existing table (max size 15) > >> > >> 0: FOO = 123 > >> 1: BAR = 321 > >> 2: BA = Z > >> > >> Substitute: TESTING = FOO at Index #0 ... > >> > >> If the size check and adjustment occurs BEFORE substitution, we end up > >> removing the first two existing indexes, causing BA = Z to be > >> renumbered as #0, then do the substitution which ends up replacing BA > >> = Z leaving "TESTING = FOO" as the only thing left in the buffer. > >> > >> If the size check occurs AFTER substitution, we replace "FOO = 123" > >> with "TESTING = FOO" then immediately drop it from the table, leaving > >> "BAR = 321" as 0 and "BA = Z" as 1. > >> > >> Pseudocode for first case: > >> > >> Entry entry > >> While (Buffer.Size + entry.Size > MAX_SIZE): > >> Buffer.Pop() > >> Buffer.replace(0, entry) > >> > >> Pseudocode for second case: > >> > >> Entry entry > >> Buffer.replace(0, entry) > >> While (Buffer.Size > MAX_SIZE): > >> Buffer.Pop() > >> > >> > >> > >> On Tue, Jul 2, 2013 at 2:42 PM, James M Snell <jasnell@gmail.com> > wrote: > >> > Need just a few simple clarifications... > >> > > >> > 1. Can the Header Table include duplicates? For instance, if the > >> > sender sends a Literal With Incremental or Substitution Indexing for a > >> > name+value that already exists in the Header Table. The sender > >> > shouldn't do this, but a buggy/malicious sender might. It's obviously > >> > bad behavior but it's not yet clear if it's an error. > >> > > >> > 2. If the sender sends a Literal with Substitution Indexing > >> > referencing an Index position that is not yet currently filled. This > >> > ought to be an error but it's not specified. For instance, let's > >> > suppose the Header Table has five entries (Index #0...4) currently and > >> > the sender sends a Substitution instruction referencing index #5. > >> > Obviously the sender is doing something wrong. > >> > > >> > 3. The Header Compression draft currently requires that header name > >> > matching in the header table be case *insensitive*. However, the > >> > current HTTP/2 implementation draft only says that HTTP Header Field > >> > names are lower cased. There is no indication in the main HTTP/2 > >> > specification indicating that ALL header names (even hypothetical > >> > non-HTTP headers that may come around later) must be lowercased. > >> > > >
Received on Tuesday, 2 July 2013 22:52:28 UTC