Request methods with hyphens

[Hiroaki Nakamura]

Hi,

2013/7/10 Maxim Dounin <mdounin at mdounin.ru>:
> Hello!
>
> On Wed, Jul 10, 2013 at 10:47:35PM +0900, Hiroaki Nakamura wrote:
>
>> Hi all,
>>
>> I found nginx rejects request methods with hyphens like
>> VERSION-CONTROL with the status code 400.
>> I got the following debug log:
>>
>> 2013/07/10 13:55:29 [info] 79048#0: *4 client sent invalid method
>> while reading client request line, client: 127.0.0.1, server:
>> localhost, request: "VERSION-CONTROL / HTTP/1.1"
>> 2013/07/10 13:55:29 [debug] 79048#0: *4 http finalize request: 400, "?" a:1, c:1
>
> Is it a method used by some real-world software?

VERSION-CONTROL is defined in the Versioning Extensions to WebDAV spec.
http://www.webdav.org/specs/rfc3253.html

>
>> I looked at the source code and found nginx will accept only 'A'-'Z'
>> and '_' as request methods.
>> http://trac.nginx.org/nginx/browser/nginx/src/http/ngx_http_parse.c?rev=626f288fa5ede7ee3cbeffe950cb9dd611e10c52#L270
>>
>> RFC2616 says the method is case-sensitive and
>> methods can have <any CHAR except CTLs or separators>
>>
>> http://tools.ietf.org/html/rfc2616#section-5.1.1
>>
>> 5.1.1 Method
>> The Method  token indicates the method to be performed on the
>>    resource identified by the Request-URI. The method is case-sensitive.
>>
>>        Method         = "OPTIONS"                ; Section 9.2
>>                       | "GET"                    ; Section 9.3
>>                       | "HEAD"                   ; Section 9.4
>>                       | "POST"                   ; Section 9.5
>>                       | "PUT"                    ; Section 9.6
>>                       | "DELETE"                 ; Section 9.7
>>                       | "TRACE"                  ; Section 9.8
>>                       | "CONNECT"                ; Section 9.9
>>                       | extension-method
>>        extension-method = token
>>
>>
>> http://tools.ietf.org/html/rfc2616#section-2.2
>>
>>        token          = 1*<any CHAR except CTLs or separators>
>>        separators     = "(" | ")" | "<" | ">" | "@"
>>                       | "," | ";" | ":" | "\" | <">
>>                       | "/" | "[" | "]" | "?" | "="
>>                       | "{" | "}" | SP | HT
>>
>>
>> Also, when a server rejects a method, the status code should be 405 or 501.
>>
>> http://tools.ietf.org/html/rfc2616#section-5.1.1
>>
>>    An origin server SHOULD return the status code 405 (Method Not Allowed)
>>    if the method is known by the origin server but not allowed for the
>>    requested resource, and 501 (Not Implemented) if the method is
>>    unrecognized or not implemented by the origin server.
>>
>> I wonder how to improve nginx on accepting or rejecting request methods.
>> Comments are welcome.
>
> As of now nginx rejects anything which isn't uppercase latin
> letters (or underscore) as syntactically invalid (and hence 400).

According to RFC2616,  any CHAR except CTLs or separators is
syntactically valid.

>
> I don't think that current behaviour should be changed unless
> there are good reasons to.  If there are good reasons, we probably
> should do something similar to underscores_in_headers, see
> http://nginx.org/r/underscores_in_headers.

I would like to use limit_except to accept only HEAD, GET and POST methods,
and return 405 (Method Not Allowed) or 501 (Not Implemented) for the
other methods.
Is this a good reason?

>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel

-- 
Hiroaki