Forum: NGINX nginx not completly http/1.1 compliant?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
88098c5295e0de78509b0febd92eb646?d=identicon&s=25 Marlon de Boer (Guest)
on 2009-02-04 17:35
(Received via mailing list)
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.h... "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
5640e332954fc0006aea97a155ce0afd?d=identicon&s=25 Igor Sysoev (Guest)
on 2009-02-04 17:56
(Received via mailing list)
On Wed, Feb 04, 2009 at 05:28:31PM +0100, Marlon de Boer wrote:

> http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.h... "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.
698ad68791be31755e0bb97efc70d243?d=identicon&s=25 Eren Türkay (Guest)
on 2009-02-04 18:12
(Received via mailing list)
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.
11511c9ae60176911be3220b3df68660?d=identicon&s=25 Matt Lewandowsky (Guest)
on 2009-02-04 18:33
(Received via mailing list)
--------------------------------------------------
From: "Marlon de Boer" <marlon@hyves.nl>
Date: Wednesday, February 04, 2009 8:28 AM
To: <nginx@sysoev.ru>
Subject: nginx not completly http/1.1 compliant?

> http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.h... "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
5447e06c6eeb471861633661aacc3659?d=identicon&s=25 luben karavelov (Guest)
on 2009-02-04 18:53
(Received via mailing list)
Matt Lewandowsky wrote:
> 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.

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
11511c9ae60176911be3220b3df68660?d=identicon&s=25 Matt Lewandowsky (Guest)
on 2009-02-04 20:18
(Received via mailing list)
I am fully aware of what's "supposed" to happen with links consisting of
solely query components. ;) 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" <luben@unixsol.org>
Date: Wednesday, February 04, 2009 9:44 AM
To: <nginx@sysoev.ru>
Subject: Re: nginx not completly http/1.1 compliant?
This topic is locked and can not be replied to.