Bug: invalid HTTP responses on invalid data

Wed Mar 17 15:10:03 MSK 2010

Hello!

On Wed, Mar 17, 2010 at 11:03:59AM +0000, david lodge wrote:

> 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>

This is perfectly valid HTTP/0.9 response to invalid HTTP/0.9 
request.  No problem here.

> 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>

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 same will happen for CONNECT method with authority specified.

Probably these two should be recognized and return 501.

Maxim Dounin