Re: h2 header field names

On 3 Sep 2014, at 11:07 pm, Poul-Henning Kamp <> wrote:

> --------
> In message <>
> , Martin Thomson writes:
>> The problem is that we're basically committed to taking pretty much
>> any old crap in values, including not just VCHAR, SP and TAB, but also
>> obs-text and even some of the ASCII control characters (BEL anyone?),
>> which HTTP/1.1 doesn't expressly permit, but we've evidence to suggest
>> that they are used, even widely.
> This is one of the "default" decisions I really don't understand.
> Just because somebody made a stupid programming mistake (the
> most common case I've seen is \0 before or after CRNL on headerlines)
> doesn't mean that we should go out of our way to propagate
> their mistake through the web for all possible future.
> There is a valid architectual question: are headers ASCII or UTF-8?
> But the lack of decision on that doesn't mean that we have to
> let through BEL, BS and ESC while we make up our mind.
> And why don't we just make the architectural decision in the
> first place ?

The time for doing that was in 2616bis. We talked about it a lot, and decided we couldn’t retroactively change the allowed values — and that doing so might not be a good idea anyway.

> 	In HTTP/2 header names are [_A-Z0-9-]* - this ensures that
> 	everybody has a chance to figure out what the header
> 	may or may not do, but the header value can be UTF-8 so we don't
> 	have to encode everything into BASE64 all the time.
> 	If Your HTTP/1 application goes beyond that ?  Stay off HTTP/2
> Now we've put a stake in the ground which web-app designers can
> navigate after, rather than the current "maybe or maybe not..."
> confusion.
> In particular I find the "all HTTP/1, valid or not, must tunnel
> through HTTP/2" position deeply confusing, when it comes from the
> same people who say they are only going to allow HTTP/2 on TLS,
> since most of the crap is on the plain-text traffic.

Mark Nottingham

Received on Thursday, 4 September 2014 06:19:38 UTC