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