Re: Restricting the HTTP method definition

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:14:46 UTC