Re: Restricting the HTTP method definition

On Tue, Aug 20, 2013 at 6:22 PM, 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]

I don't see how the bug mentioned in the blog has anything to do with
what you are proposing. It looks like node.js is accepting any "GE<*>"
as "GET" where <*> can be any octet. Maybe node.js was assuming that
the request has been validated by an upstream parser?

Zhong Yu

Received on Wednesday, 21 August 2013 15:07:32 UTC