400 Bad Request and spaces

Forum Moderators: phranque

Message Too Old, No Replies

400 Bad Request and spaces

apache handling of spaces in urls

faz_matt

11:51 pm on May 21, 2007 (gmt 0)

I have an application that is requesting files from an apache webserver, it is quite an old app and does not escape spaces in the url, so it is sending something like

"http://webserver/file name with spaces.txt HTTP/1.0"
instead of
"http://webserver/file%20name%20with%20spaces.txt HTTP/1.0"

This works fine on my local copy of apache, I think it ignores the malformed url and just assumes that it is http 1.0. But on any production server I try to use it on, I get 400 bad request responses.

Does anyone know how I can set my server here to be the same as what appears to the the norm and send back 400 responses.

I need to be able to find the difference between the setups, but I do not have access to the http.conf of the live server, as it is a shared host. The only reference I can find to this is in the apache directive

ProtocolReqCheck off

But this appears to only be available in apache 1.3, I am using apache 2.0

jdMorgan

1:07 pm on May 22, 2007 (gmt 0)

You might be able to force errors using mod_alias:


RedirectMatch 400 ^[^\ ]*\ [^\ ]*$

I'm not sure if that will work -- I've never actually tried it. See Apache mod_alias, especially the note under the Redirect description regarding the response code and the presence or absence of the redirect-URL.

The problem is that unescaped spaces in request headers are considered to be delimiters by the HTTP protocol. Any unescaped space indicates the end of one parameter and the beginning of the next. A valid request is laid out like this:
<HTTP Method> <space> <URL-path> <space> <protocol and version> <newline>
e.g. "GET /index.html HTTP/1.1"

So by injecting unescaped spaces, for example
GET /my index.html HTTP/1.0
you confuse the parser, which would see the requested method as "GET", the URL-path as "my", the protocol as "index.html", and would then find an extra/unexpected parameter on the end, "HTTP/1.0".

So it would find both the request protocol and the parameter count to be incorrect.

The fact that your test server accepts these unescaped spaces might also be because of a difference in the operating systems of your test and live servers -- It's possible the protocol stack is fixing up the invalid requests.

Jim