Missing slash and error 400 / bad Request

Server NGINX
1

Hello,

i’m trying to use Nginx as a reverse proxy, and i get some troubles due
to a
missing “/” in the HTTP header sant by a client application.
The HTTP/GET header is “GET index.html HTTP/1.1” and it seems that it
should
be “GET /index.html HTTP/1.1”. This causes an error 400 (nginx logs
confirms
this).

knowing that the client application cannot be modified, is their a way
to
configure Nginx so that it accepts this request ?

Thank you.

2

On Tue, Nov 03, 2009 at 02:51:38AM -0800, cheinsow wrote:

i’m trying to use Nginx as a reverse proxy, and i get some troubles due to a
missing “/” in the HTTP header sant by a client application.
The HTTP/GET header is “GET index.html HTTP/1.1” and it seems that it should
be “GET /index.html HTTP/1.1”. This causes an error 400 (nginx logs confirms
this).

knowing that the client application cannot be modified, is their a way to
configure Nginx so that it accepts this request ?

Do the client work with other web servers ?
Apache should return 400 error on such request too.

3

I never tried with Apche, but it works with lightTPD. I got some other
issues
with lightTPD (essentially high CPU usage), that’s why I’m trying to
replace
it with Nginx.

4

Hello!

On Tue, Nov 03, 2009 at 05:07:01AM -0800, cheinsow wrote:

I never tried with Apche, but it works with lightTPD. I got some other issues
with lightTPD (essentially high CPU usage), that’s why I’m trying to replace
it with Nginx.

Actually, it doesn’t matter how apache or lighty handle this.
There are two basic points should be considered here:

  1. What RFC 2616 says.

  2. What real life says (i.e. if there are any clients using it).

RFC 2616 looks very clear here:

Request-Line = Method SP Request-URI SP HTTP-Version CRLF
Request-URI = “*” | absoluteURI | abs_path | authority

it adopts “absoluteURI”, “abs_path” and “authority” definitions
from RFC 2396:

absoluteURI = scheme “:” ( hier_part | opaque_part )
abs_path = “/” path_segments

Obviously “index.html” isn’t an absoluteURI (must contain “:”), and
isn’t an abs_path (must start with “/”).

So “GET index.html HTTP/1.1” is only valid assuming “index.html”
is authority. On the other hand, RFC 2616 says in “5.1.2
Request-URI”:

% The authority form is only used by the CONNECT method (section
% 9.9).

That is, “GET index.html HTTP/1.1” is invalid per RFC 2616. It’s
not HTTP. And nginx rightfully returns 400 here.

So we here back to question (2). What client produced request in
question? Is it common enough to add compatibility shims and
accept non-http requests from it?

Maxim D.

5

Thanks for your reply. I’m perfectly aware that this client do not
respect
RFS’s, but unfortunately I cannot modify it.
I just wanted to know if they were some “configuration tricks” to make
nginx
accept this http request.

The client application is very specific, and of course it’s not common
enough to require nginx to be modified to handle it’s requests.

6

On Tue, Nov 03, 2009 at 08:17:04AM -0800, cheinsow wrote:

Thanks for your reply. I’m perfectly aware that this client do not respect
RFS’s, but unfortunately I cannot modify it.
I just wanted to know if they were some “configuration tricks” to make nginx
accept this http request.

No, nginx requires “/” in URI start.