Re: Restricting the HTTP method definition

I don't really care about this-- it solves none of my problems.

I typically scan for the EOL, checking length while doing this 8 or more
characters at a time, then, once the EOL is discovered, attempt to parse
the tokens within the first line.
I care about the total length of the first line, but even then only because
I care about the total size of the headers since I don't want to exceed
available memory and die.
I don't care if it is spent in the method, uri, headers, p3p, cookie, or
whatever. It is all the same crud to me-- it just has to fit in the
available space.
If the particular server cares about accepting a limited set of methods
(which is always true-- if you don't know what a verb is, you don't know
what to do with it...), then the request is rejected.

What problem does limiting the verb sizes solve? Are people doing weird
things with them? Are people abusing them in ways that would cause problems
that they cannot otherwise do (e.g. with a very long path)?
-=R



On Tue, Aug 20, 2013 at 5:18 PM, James M Snell <jasnell@gmail.com> wrote:

> 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/
> >
> >
> >
>
>