Bug: invalid HTTP responses on invalid data

Wed Mar 17 14:03:59 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.

For example if I send a request with a lower case "get" method, I'd
expect the webserver to return an HTTP 400 message, but with nginx we
find:

D:\tools\netcat>echo "a" | nc 127.0.0.1 80
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/0.7.65</center>
</body>
</html>

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
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/0.7.65</center>
</body>
</html>

I can understand why the stream is immediately terminated, that it
minimises risk of out of band data. But the response should include a
valid HTTP code and be conformant to the RFC, just like a request for
TEST / HTTP/1.1 does:
HTTP/1.1 400 Bad Request
Server: nginx/0.7.65
Date: Wed, 17 Mar 2010 11:03:27 GMT
Content-Type: text/html
Content-Length: 173
Connection: close

<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/0.7.65</center>
</body>
</html>