Nginx not completly http/1.1 compliant?

Server NGINX
1

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/1.1: Request “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?

Regards
Marlon

2

On Wednesday 04 February 2009 18:28:31 Marlon de Boer wrote:

GET ?var=something HTTP/1.1
host: somehost.com

It should be " GET /?var=something HTTP/1.1 "

You don’t pass which URL to get thus nginx normally gives bad request
error.

3

On Wed, Feb 04, 2009 at 05:28:31PM +0100, Marlon de Boer wrote:

HTTP/1.1: Request “Note
that the absolute path cannot be empty; if none is present in the
original URI, it MUST be given as “/” (the server root).”

As I understand this sentence, this means that a client MUST send
absolute path.

4

From: “Marlon de Boer” [email protected]
Date: Wednesday, February 04, 2009 8:28 AM
To: [email protected]
Subject: nginx not completly http/1.1 compliant?

HTTP/1.1: Request “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 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. :smiley:

Warmest,

–Matt
5

Matt Lewandowsky wrote:

I suspect that coming across
links like isn’t overly common and the exotic UAs
may not have tested such links.

The meaning of such a links is that the UA should call the same absolute
path with different GET params. It does not mean that there is no
absolute path.

luben

6

I am fully aware of what’s “supposed” to happen with links consisting of
solely query components. :wink: However, such links are somewhat uncommon
and
may not be tested in “non-standard” browsers. Though, as it’s a basic
part
of the spec, I’d be hesitant to trust a UA that can’t even get that
right…
But, at the same time, I’d try to make it a point to not have my pages
generate that style of URL. As Jon Postel said best, “Be liberal in what
you
accept, and conservative in what you send.”

Keep in mind that even now, there are still browsers out there that
don’t
properly handle fragments. They may be rare, but I do get the occasional
request for “#fragmentname” in my error logs. I can only assume that
there
are a few browsers which would also request “?foo=bar” without an
absolute
path, and it’s probably not an unfair assumption…

–Matt

From: “luben karavelov” [email protected]
Date: Wednesday, February 04, 2009 9:44 AM
To: [email protected]
Subject: Re: nginx not completly http/1.1 compliant?