Bug: invalid HTTP responses on invalid data

Maxim Dounin mdounin at mdounin.ru
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



More information about the nginx mailing list