Bug: invalid HTTP responses on invalid data

Wed Mar 17 15:43:41 MSK 2010

>> Nginx seems to offer some strange behaviour when it receives invalid
>> tokens in the HTTP request. If an unexpected character is sent then
>> the stream will immediately terminate, returning an HTML page for the
>> 400 error. More importantly, this response does not contain a valid
>> HTTP 400 code.
>> D:\tools\netcat>echo "a" | nc 127.0.0.1 80
>> <html>
> This is perfectly valid HTTP/0.9 response to invalid HTTP/0.9
> request.  No problem here.

That'd make sense, though looking at RFC1945 it does seem that it
should only return a HTTP/0.9 response if a simple-request is sent:

Simple-Request  = "GET" SP Request-URI CRLF

Which is sort of messed up as it terminates the stream as soon as it
reads an out-of-bands character, so even if I send "get / HTTP/1.1"
I'll still get the HTTP/0.9 message (as the connection will terminate
of the "g").

(Of course it is feasible, though unlikely, that an HTTP method could
be called "get" which wouldn't be the same as "GET".)

>> Similarly with an OPTIONS * HTTP/1.1 request (which is a valid HTTP
>> request - as it should return options valid to the server, not to a
>> URI):
>> D:\tools\netcat>echo "OPTIONS * HTTP/1.1" | nc 127.0.0.1 80
> This seems to be bug indeed.  nginx doesn't support OPTIONS, and
> doesn't correctly recognize this as HTTP/1.1 request as it
> contains '*' (which is only allowed in OPTIONS).

The problem being that as soon as nginx sees an "*" in the URI
location it will terminate the stream, e.g. if you give a URI of
http://127.0.0.1/fred?jim=*

The RFCs are contradictory on this - 1945 (HTTP/1.0 and 0/9) says that
* is valid in a URI; 2616 (HTTP/1.1) says that * is a special case
that refers to the server, not to a specific resource.

> Probably these two should be recognized and return 501.

Would 405 (method not allowed) be better for an unknown method than
501 (not implemented)?

This is *not* a serious issue and I only found it because I'm testing
edge cases on web servers. Most normal use wouldn't even see this
behaviour (though it is possible for a badly implemented agent to send
a * as a cgi parameter, in which case it could become prominent).

dave