W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: h2 header field names

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 4 Sep 2014 09:18:31 +0300
Cc: Martin Thomson <martin.thomson@gmail.com>, Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1AB5985B-A9F8-40BE-B4D7-70EC84FBF4E8@mnot.net>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

On 3 Sep 2014, at 11:07 pm, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

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

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   http://www.mnot.net/
Received on Thursday, 4 September 2014 06:19:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC