- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 4 Sep 2014 09:18:31 +0300
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
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