Re: Header Compression Clarifications

1: There is currently no prohibition against this.
2: seems reasonable
3: I think we should change that so we only deal with lowercased keys
consistently.


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