Subject: Permitted characters for http keys

From: Roberto Peon <[email-masked]>
Date: Tue, 19 Feb 2013 12:45:22 -0800

Right now I believe we allow a wider encoding for HTTP keys than is
necessary.

Does anyone know of any non-crazy use for character values > 127 in the
header keys (because I really can't think of any)?

-=R

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 Feb 2013 13:10:17 -0800

> Right now I believe we allow a wider encoding for HTTP keys than is

Actually, you might be able to get the acceptable set down to a lot
less.  64 seems relatively easy, and that still allows for both upper
and lower case.

> header keys (because I really can't think of any)?

I can't.  That doesn't mean that someone else wont think their reason non-crazy.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 25 Feb 2013 17:57:19 +0900

Hello Roberto,

What do you mean with "header key"? Do you mean header field names? E.g. 
the "Host" in the host header (field), and so on?

In that case, I agree. Please note that [RFC5322] allows all US-ASCII 
printable characters except ":" in optional header field names (Section 
3.6.8). I had to learn this (and the "header field", "header field 
name",... terminology) while working on RFC 6068.

I'm not sure this also applies to HTTP, but it may as well do so. Of 
course, a header field name like "^$&%*@(!]" really makes no sense at 
all, but that's a separate issue.

Regards,   Martin.

On 2013/02/20 5:45, Roberto Peon wrote:
> Does anyone know of any non-crazy use for character values>  127 in the

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 25 Feb 2013 21:33:51 +1100

Right now, the syntax is:

  header-field   = field-name ":" OWS field-value BWS
  field-name     = token
  token          = 1*tchar
  tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                    / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 
                    / DIGIT / ALPHA ; any VCHAR, except special

On 25/02/2013, at 7:57 PM, Martin J. Dürst <[email-masked]> wrote:

> Hello Roberto,
> 
> What do you mean with "header key"? Do you mean header field names? E.g. the "Host" in the host header (field), and so on?
> 
> In that case, I agree. Please note that [RFC5322] allows all US-ASCII printable characters except ":" in optional header field names (Section 3.6.8). I had to learn this (and the "header field", "header field name",... terminology) while working on RFC 6068.
> 
> I'm not sure this also applies to HTTP, but it may as well do so. Of course, a header field name like "^$&%*@(!]" really makes no sense at all, but that's a separate issue.
> 
> Regards,   Martin.
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Mon, 25 Feb 2013 07:58:46 -0800

Could we get away with redefining this as simply...

    "-" / "." / "_"  / DIGIT / ALPHA

With an 8-bit length restriction? (That is, length represent by a single
unsigned byte)

Given all evidence of current practice, these constraints appear quite
reasonable.
 On Feb 25, 2013 2:36 AM, "Mark Nottingham" <[email-masked]> wrote:

> course, a header field name like "^$&%*@(!]" really makes no sense at all,
> but that's a separate issue.
> >
> > Regards,   Martin.
> >

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Feb 2013 10:02:18 +1100

I'd be really, really wary of this. They may not be standard or common, but I've seen many headers that exercise the stranger characters available, and having them break in HTTP/2 would not be good.

Cheers,

On 26/02/2013, at 2:58 AM, James M Snell <[email-masked]> wrote:

> With an 8-bit length restriction? (That is, length represent by a single unsigned byte)
> 
> Given all evidence of current practice, these constraints appear quite reasonable.

---

From: James M Snell <[email-masked]>
Date: Mon, 25 Feb 2013 15:26:46 -0800

Sigh.. ok, how about the part about limiting header field name length
to <= 0xFF?

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Feb 2013 10:31:06 +1100

Yeah, personally I'd agree that 32 bits is a bit much...
   http://http2.github.com/http2-spec/#HeaderBlock

Say, 8 bits?

(opening as <https://github.com/http2/http2-spec/issues/41>)

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 26 Feb 2013 17:31:34 +1300

> (opening as <https://github.com/http2/http2-spec/issues/41>)

+1 on 8 bits.

smaller would seem to be better, but 8-bit alignment is reasonable.

> On 26/02/2013, at 10:26 AM, James M Snell wrote:
>
>> On Mon, Feb 25, 2013 at 3:02 PM, Mark Nottingham wrote:

Examples? and are the custom ones or

Can the definition be narrowed down in the HTTPbis drafts to remove some 
of the characters not even being used by these exceptional cases?

Amos

---

From: RUELLAN Herve <[email-masked]>
Date: Tue, 26 Feb 2013 09:03:52 +0000

Yes, 8 bits should be sufficient.

>From my stats, the longest header name I found is 32 character long (access-control-allow-credentials): this means 6 bits !

However, I would defer the exact decision to the definition of the header encoding format: 1 byte could be used to carry a 1 bit flag and the length of the header name.

Hervé.

> -----Original Message-----
> From: Amos Jeffries [mailto:[email-masked]]
> Sent: mardi 26 février 2013 05:32
> To: [email-masked]
> Subject: Re: #41: Header Block field name length
> 
> >>> I'd be really, really wary of this. They may not be standard or common,
> but I've seen many headers that exercise the stranger characters available,
> and having them break in HTTP/2 would not be good.
>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 26 Feb 2013 12:48:42 -0800

I think this section will be changing with the compression scheme anyway,
and it probably isn't worth making changes to this right now.
-=R

On Tue, Feb 26, 2013 at 1:03 AM, RUELLAN Herve
<[email-masked]>wrote:

> >From my stats, the longest header name I found is 32 character long
> (access-control-allow-credentials): this means 6 bits !
>
> However, I would defer the exact decision to the definition of the header
> encoding format: 1 byte could be used to carry a 1 bit flag and the length
> of the header name.
>
> Hervé.
>