- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 20 Aug 2013 17:18:51 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Ok. Same note. Same mailing list. Same proposal. s/HTTP\/2/HTTP\/1/g. Regardless of exactly which doc to do it in, it ought to be done. On Tue, Aug 20, 2013 at 5:14 PM, Mark Nottingham <mnot@mnot.net> wrote: > James, > > The place to do that is HTTP/1, not HTTP/2. > > Cheers, > > > On 21/08/2013, at 9:22 AM, James M Snell <jasnell@gmail.com> wrote: > >> HTTPbis currently defines the request method as a "token" of unbounded-length. >> >> Specifically: >> >> tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / >> "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA >> token = 1*tchar >> method = token >> >> This definition is overly broad and does not reflect real world use >> [http://tools.ietf.org/html/draft-ietf-httpbis-method-registrations-12]. >> >> I propose that in HTTP/2 we tighten this definition up significantly >> and place an upper bound on the length a request method ought to be: >> >> UPPER = %x41-5A >> method = UPPER *20( UPPER / "_" / "-" ) >> >> This is obviously a strictly limited subset of what's allowed by the >> current definition. It limits the length of method names to no more >> than 20 characters, requires that methods be all uppercase, requires >> that methods always start with a letter and limits non-letter >> characters to the dash and underscore. The rule would be that all >> *newly registered* HTTP methods MUST conform to the new rule but >> implementations MAY choose to support the old definition if necessary >> for backwards compatibility. >> >> It's a fairly minor issue, yes, but tightening this up ought to make >> it easier for developers to create parsers that are both efficient >> *and* compliant [http://www.chmod777self.com/2013/08/sigh.html] >> >> - James >> > > -- > Mark Nottingham http://www.mnot.net/ > > >
Received on Wednesday, 21 August 2013 00:19:39 UTC