Re: Header Compression Clarifications

Herve is probably not available yet, but I suspect he might argue the other
way...
-=R


On Tue, Jul 2, 2013 at 3:52 PM, Roberto Peon <grmocg@gmail.com> wrote:

> 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.
>> >>
>> >
>>
>
>