Re: h2 header field names

--------
In message <CABkgnnWPsmJqRtd0w2TxULZrfue9PkeFjJAXZQk_qfSfQbb-gg@mail.gmail.com>
, 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 ?

	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.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Wednesday, 3 September 2014 20:07:32 UTC