Hi, 2013/7/10 Maxim Dounin <mdou...@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@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel -- Hiroaki _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
