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

Restricting the HTTP method definition

From: James M Snell <jasnell@gmail.com>
Date: Tue, 20 Aug 2013 16:22:15 -0700
Message-ID: <CABP7RbeBvs=FofkBV=E97uVPxA46bVpb7EB_hJ=0o1f1xi0faQ@mail.gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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
Received on Tuesday, 20 August 2013 23:23:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC