Re: Restricting the HTTP method definition

I admit that I haven't thought hard about how this might potentially be
abused with others' frameworks/servers, but I imagine the pattern is nearly
always the same:

Servers/Clients which care about security/memory utilization will ensure
that this won't be abused.
Servers/Clients that trade reliability for simplicity will occasionally
suffer decreased reliability when they receive strange input.

In the end, I don't think there is anything we can do for the
servers/clients in the latter case. If we constrain the input so much that
it is always safe, it is likely we have created something which is not
generally useful.

-=R


On Tue, Aug 20, 2013 at 5:37 PM, Roberto Peon <grmocg@gmail.com> wrote:

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