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

Re: Header Compression Clarifications

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 2 Jul 2013 15:52:01 -0700
Message-ID: <CAP+FsNfTKafw8U1i+qof4kdkpnZ2i05rQan4UoDgLgMidaf2PQ@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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

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