Subject: Uppercase/lowercase header field names

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2013 17:15:27 -0700

With the decision to have header compression treat header data as
opaque bytes, we're back to the old problem we never solved regarding
the requirement to downcase header field names.  In fact, it was
missing from -06 and no one noticed.

I've put in a fix for this:
https://github.com/http2/http2-spec/commit/115bc86868c8ff35a52219bda31e17baea24f088

The trick here is that I've marked requests and responses that contain
uppercase names as malformed.  That means that they fall under the
same rules as requests without a target URI, responses without status
codes, messages that include verboten header fields (e.g., TE or
Connection), and messages with conflicting content-length values.

The upshot is that we are allowing forwarding if you aren't looking at
the headers (the B2BUA concepts from the SIP world would be really
handy at this point to explain this particular distinction), but
requiring that:

a) malformed requests fail (with an HTTP response being optional)

b) malformed requests aren't passed to applications

I don't think that this constitutes a change of intent, but I'd like
to pass this under people's noses before shipping a new revision.  As
always, pull requests are happily received.

--Martin

---

From: Fred Akalin <[email-masked]>
Date: Tue, 15 Oct 2013 17:21:14 -0700

> missing from -06 and no one noticed.

Just to clarify, we decided to treat header *values* as opaque bytes.
Header names are still constrained to have only lowercase alpha characters
(see 4.1.2 in
http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-03).

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2013 20:33:05 -0700

On 15 October 2013 17:21, Fred Akalin <[email-masked]> wrote:
> Just to clarify, we decided to treat header *values* as opaque bytes. Header
> names are still constrained to have only lowercase alpha characters (see
> 4.1.2 in

Of course, so I wonder why Herve raised #277...  Still, I like the new
edits, so I'm gonna keep 'em.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 16 Oct 2013 17:04:49 +1300

On 16/10/2013 4:33 p.m., Martin Thomson wrote:
> On 15 October 2013 17:21, Fred Akalin wrote:

I see one problem...

The details about content-length specify that the response is malformed 
if it does not match the sum of DATA lengths. This is not a details 
which can be known in advance yet intermediaries are faced with the 
requirement of forwarding only being permitted "if the frames are 
forwarded without inspection of header fields". So intermediaries are 
thus required to wait and buffer all DATA of a response with 
content-length set to be received before they discover whether it is 
permitted to forward.
  This is an impossible requirement. It needs to be possible to forward 
responses which are not already known to be malformed, even if they turn 
out to be so by the end of the transaction.

Amos

---

From: RUELLAN Herve <[email-masked]>
Date: Thu, 17 Oct 2013 12:31:28 +0000

From my understanding, we decided in Seattle that Header names would also be opaque bytes.

I made the changes accordingly in the HPack spec on github.

Hervé.

> -----Original Message-----
> From: Fred Akalin [mailto:[email-masked]]
> Sent: mercredi 16 octobre 2013 02:21
> To: Martin Thomson
> Cc: HTTP Working Group
> Subject: Re: Uppercase/lowercase header field names
> 
> On Tue, Oct 15, 2013 at 5:15 PM, Martin Thomson
> <[email-masked]> wrote:
> 
> 
> names are still constrained to have only lowercase alpha characters (see 4.1.2
> in http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-03).