Bug #406
closedPHP PATH_INFO improperly converted to lowercase
Description
I am evaluating lighttpd-1.4.8 as a replacement for apache2. I am using PHP 5.1.1 on Mac OS X 10.4.3.
A show-stopping bug I've discovered is that in many $_SERVER variables, the paths are converted to lowercase. My projects require the user-supplied case to be preserved. Projects in the wild that I can think of that also care about the case of URLs would include MediaWiki.
For example, if I have a script Server.php with this contents:
<?php print_r($_SERVER); ?>
and I try to access it this way:
http://fusion.local/rcs/test/Server.php/HelloWorld
then the relevant portions of the output are as follows:
[[SCRIPT_NAME]] => /rcs/test/server.php
[[PATH_INFO]] => /helloworld
[[PATH_TRANSLATED]] => /web/fusion/htdocs/helloworld
[[SCRIPT_FILENAME]] => /web/fusion/htdocs/rcs/test/server.php
[[REQUEST_URI]] => /rcs/test/Server.php/HelloWorld
[[ORIG_PATH_TRANSLATED]] => /web/fusion/htdocs//helloworld
[[ORIG_PATH_INFO]] => /helloworld
[[ORIG_SCRIPT_NAME]] => /rcs/test/Server.php
[[ORIG_SCRIPT_FILENAME]] => /web/fusion/htdocs/rcs/test/server.php/helloworld
[[PHP_SELF]] => /rcs/test/server.php
SCRIPT_NAME, PATH_INFO, PATH_TRANSLATED, SCRIPT_FILENAME, ORIG_PATH_TRANSLATED, ORIG_PATH_INFO, ORIG_SCRIPT_FILENAME and PHP_SELF have all been improperly converted to lowercase.
-- lighttpd-2005
Updated by Anonymous almost 19 years ago
We also have this problem with using lighttpd reddit.com. We had to build a workaround that tries to get PATH_INFO from the REQUEST_URI.
-- me
Updated by jan almost 19 years ago
- Status changed from New to Assigned
We do this on purpose as the filesystem was detected to case-insensitive.
Otherwise you would have problems like:
url.access-deny = ( ".inc" )
http://www.example.com/config.inc -> 403 (denied)
http://www.example.com/config.INC -> 200 (ok)
or .php would be process by PHP and .PHP would be served directly.
Up to now I don't see an easy way to clean up the path this way and keep the PATHINFO intact.
Updated by Anonymous almost 18 years ago
This bit me setting up a MediaWiki dev testing environment on my new MacBook. It rather effectively kills MediaWiki's use of PATH_INFO, resulting in a broken out-of-the-box install for the latest dev code (which tries to detect that PATH_INFO is set up correctly for CGI, but... in this case it ain't.)
Offhand, wouldn't it make more sense to do case-insensitive matches for the url.access-deny etc, rather than corrupting the data sent to scripts?
-- brion
Updated by Anonymous over 16 years ago
Has this been fixed or is there a way to force the detection as case-sensitive? I'm working on OS X but all my website are on a case-sensitive HFS+ sparseimage to match our production servers.
Any page/script/file not fully lower-case returns a 404 instead of the actual content which is really annoying.
-- hugues.lismonde
Updated by Seldaek over 16 years ago
I don't need this as I run lighty on debian, but couldn't this be fixed by turning all matching functions to be case-insensitive (i.e. regex /i switch and I'm not sure how for other functions) ? It would make more sense than lowercasing the pathinfo imo. Or at least it should be passed correctly in the ORIG_PATH_INFO.
Updated by stbuehler about 16 years ago
- Status changed from Assigned to Fixed
- Resolution set to wontfix
server.force-lowercase-filenames = "disable"
You will get the problems described by jan of course - i see no good way to fix it. (we will not turn all other functions case-insensitive, as case-insensitive is stupid imho).
REQUEST_URI should contain the original request uri if you need it.
Updated by gstrauss over 8 years ago
- Description updated (diff)
- Status changed from Wontfix to Patch Pending
- Target version set to 1.4.40
The following (untested!) patch should fix this for vast majority of use cases.
Would someone affected by this test and confirm?
diff --git a/src/response.c b/src/response.c index 3763f26..67469ef 100644 --- a/src/response.c +++ b/src/response.c @@ -697,13 +697,24 @@ handler_t http_response_prepare(server *srv, connection *con) { /* we have a PATHINFO */ if (pathinfo) { - buffer_copy_string(con->request.pathinfo, pathinfo); + size_t len = strlen(pathinfo), reqlen; + if (con->conf.force_lowercase_filenames + && len <= (reqlen = buffer_string_length(con->request.uri)) + && 0 == strncasecmp(con->request.uri->ptr + reqlen - len, pathinfo, len)) { + /* attempt to preserve case-insensitive PATH_INFO + * (works in common case where mod_alias, mod_magnet, and other modules + * have not modified the PATH_INFO portion of request URI, or did so + * with exactly the PATH_INFO desired) */ + buffer_copy_string_len(con->request.pathinfo, con->request.uri->ptr + reqlen - len, len); + } else { + buffer_copy_string_len(con->request.pathinfo, pathinfo, len); + } /* * shorten uri.path */ - buffer_string_set_length(con->uri.path, buffer_string_length(con->uri.path) - strlen(pathinfo)); + buffer_string_set_length(con->uri.path, buffer_string_length(con->uri.path) - len); } if (con->conf.log_request_handling) {
Updated by gstrauss over 8 years ago
- Subject changed from PHP SCRIPT_NAME, PATH_INFO, PHP_SELF and others improperly converted to lowercase to PHP PATH_INFO improperly converted to lowercase
I have committed patch to preserve the case of PATH_INFO when the target filesystem is case-insensitive.
However, regard the other variables that have been lowercased, when the target filesystem is case-insensitive, the physical path is lowercased for consistency.
Updated by gstrauss over 8 years ago
- Status changed from Patch Pending to Fixed
- % Done changed from 0 to 100
Applied in changeset 4edb65cfa1a32e62a98e38bf21cda9542e0bda2d.
Also available in: Atom