W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Header Compression Clarifications

From: James M Snell <jasnell@gmail.com>
Date: Tue, 2 Jul 2013 15:50:58 -0700
Message-ID: <CABP7Rbc8RbBsoFbTjxhcYgZz_-0CaKTQb3nxjEnDBUp_V9m1uQ@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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:51:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC