Re: Header Compression Clarifications

I take that back-- ( I didn't have a substitution mode in delta, so I have
to page back in discussions with Herve from some time ago now :) )
What should be illegal is referencing a slot which doesn't have anything in
it.

If it does have something in it, you continue popping stuff until you can
put it in. That may end up clearing the table entirely.

We do need to clarify what happens when you attempt to stick something in
there which is, ont its own + entry overhead > max state size (I think the
safest thing is that we declare that a protocol error).

So, an example:
Imagine that you're replacing entry #10 with something 10 characters long.
The previous entry in that slot was 5 characters long, and the table was
already at max size.
This implies that you need to get rid of 5 characters before replacing.
Assuming that items 1 and 2 are the oldest items and item 1 is 3 chars, and
item 2 is 3 chars, you need to pop two.

You now stick the 10 characters into what was formerly entry #10.

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