Re: Header Compression Clarifications

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:06:07 UTC