Nginx/1.3.2 - 4xx responses are returned without HTTP headers, bug?

aris · July 9, 2012, 10:50am

Hi,

I think I stumbled upon a bug in nginx but I would like to get someone
else’s opinion on this.

It seems all 4xx errors are not prefixed by headers in HTTP responses. I
have a simple test-script in bash which you can run to verify this
behavior:

function req { echo -n “GET /bugtest?id=”; for i in seq 15000 17100 ;
do echo -n “%7C$i” ; done ; echo -en “HTTP/1.1\nUser-Agent:
Mozilla/5.0\nConnection: Close\nHost: wiki.nginx.org\r\n\r\n” ; } ; req
| nc wiki.nginx.org 80

I can also reproduce this for other 4xx responses. My interpretation of
the RFC is that this is unwanted, see

If this is not the appropriate place to report this please let me know
as I couldn’t find a better place to report this.

–

Regards,

Sjon Hortensius

Sjon_Hortensius · July 9, 2012, 11:53am

Hello!

On Mon, Jul 09, 2012 at 10:41:19AM +0200, Sjon Hortensius wrote:

17100` ; do echo -n “%7C$i” ; done ; echo -en “HTTP/1.1\nUser-Agent:
Mozilla/5.0\nConnection: Close\nHost: wiki.nginx.org\r\n\r\n” ; } ;
req | nc wiki.nginx.org 80

I can also reproduce this for other 4xx responses. My interpretation
of the RFC is that this is unwanted, see
RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1

Headers aren’t sent if nginx assumes the request is in HTTP/0.9
format. The above script makes nginx to think it’s HTTP/0.9 as
uri used dosn’t fit into header buffer and nginx isn’t able to
see “HTTP/1.1” before it returns 414.

Maxim D.

Sjon_Hortensius · July 9, 2012, 1:02pm

On 07/09/2012 11:52 AM, Maxim D. wrote:

responses. I have a simple test-script in bash which you can run to

Headers aren’t sent if nginx assumes the request is in HTTP/0.9
format. The above script makes nginx to think it’s HTTP/0.9 as
uri used dosn’t fit into header buffer and nginx isn’t able to
see “HTTP/1.1” before it returns 414.

Maxim D.

Thanks for your reply! I have been looking for RFC documents describing
the maximum request-length in HTTP/0.9, but I cannot find any. I found
HTTP: The Request (which links to
Uniform Resource Locators: BNF to describe URLs) and
http://www.ietf.org/rfc/rfc1738.txt, both of which describe no maximum
length.

If nginx assumes HTTP/0.9 for the request, it doesn’t seem very logical
to return an error which cannot exist within that very protocol?

–

Regards,

Sjon Hortensius

Sjon_Hortensius · July 9, 2012, 2:46pm

On Mon, Jul 09, 2012 at 01:01:21PM +0200, Sjon Hortensius wrote:

It seems all 4xx errors are not prefixed by headers in HTTP
RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
HTTP: The Request (which links to
Uniform Resource Locators: BNF to describe URLs) and
http://www.ietf.org/rfc/rfc1738.txt, both of which describe no maximum
length.

If nginx assumes HTTP/0.9 for the request, it doesn’t seem very logical
to return an error which cannot exist within that very protocol?

Well, it does not return error. It just returns a page with text:
“414 Request-URI Too Large”. What can you suggest to return for
a request larger than configured buffer ?

–
Igor S.

Sjon_Hortensius · July 10, 2012, 12:11pm

On 07/09/2012 02:46 PM, Igor S. wrote:

of the RFC is that this is unwanted, see
the maximum request-length in HTTP/0.9, but I cannot find any. I found
a request larger than configured buffer ?
When I said it returns an error I obviously meant it returns a HTTP
error. Since HTTP/0.9 doesn’t define a maximum length for a URL, it
seems strange to return an error about this very length in this specific
protocol.

I think the only problem I have with this behavior is nginx falling back
to HTTP/0.9; a protocol which isn’t used on any network I know. I would
prefer falling back to HTTP/1.0 which more clients will support,
although I don’t know what impact this has.

–

Regards,

Sjon Hortensius