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? > 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). 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. -- Maxim Dounin http://nginx.org/en/donation.html _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel