nginx not completly http/1.1 compliant?

Matt Lewandowsky matt at nepheliad.net
Wed Feb 4 20:24:30 MSK 2009


--------------------------------------------------
From: "Marlon de Boer" <marlon at hyves.nl>
Date: Wednesday, February 04, 2009 8:28 AM
To: <nginx at sysoev.ru>
Subject: nginx not completly http/1.1 compliant?

> Hi list,
>
> If I request the following url
>
> GET ?var=something HTTP/1.1
> host: somehost.com
>
> Nginx returns an error saying 400 Bad Request.
>
> According to
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.2 "Note
> that the absolute path cannot be empty; if none is present in the
> original URI, it MUST be given as "/" (the server root)."
>
> I'm running 0.6.29, looked at the changelog for all stable releases but
> saw no fixes for this, is this a bug? or is the above GET request
> officially incorrect?

I'd say it's "officially incorrect". As the section you quoted states, "the 
absolute path cannot be empty". A query component is definitely not part of 
an absolute path. (See RFC2396 for more info on the syntax of URIs.) So, the 
conformant request would be:

GET /?var=something HTTP/1.1
Host: example.com

In my opinion, any app that generates only query strings as URLs and doesn't 
include a path is waiting for breakage. Though a client "MUST" include / if 
there is no absolute path, there may still be UAs out there which are not 
conformant in this aspect. I suspect that coming across links like <a 
href="?fdas=affa"> isn't overly common and the exotic UAs may not have 
tested such links.

But, in the end, a 400 is a perfectly valid response from nginx. If other 
web servers do not generate a 400 (or maybe a 406, offering a link to a sane 
URI), you should file bugs against them. :D

Warmest,

--Matt 






More information about the nginx mailing list