Welcome! Log In Create A New Profile

Advanced

Re: Bug: invalid HTTP responses on invalid data

david lodge
March 17, 2010 08:48AM
>> 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

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx
Subject Author Posted

Bug: invalid HTTP responses on invalid data

david lodge March 17, 2010 07:08AM

Re: Bug: invalid HTTP responses on invalid data

Maxim Dounin March 17, 2010 08:14AM

Re: Bug: invalid HTTP responses on invalid data

Kirill A. Korinskiy March 17, 2010 08:18AM

Re: Bug: invalid HTTP responses on invalid data

Maxim Dounin March 17, 2010 08:36AM

Re: Bug: invalid HTTP responses on invalid data

david lodge March 17, 2010 08:48AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 45
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready