Project

General

Profile

Bug #406

PHP PATH_INFO improperly converted to lowercase

Added by Anonymous about 12 years ago. Updated over 1 year ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
core
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Missing in 1.5.x:

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

Associated revisions

Revision 4edb65cf (diff)
Added by gstrauss over 1 year ago

[core] preserve PATH_INFO case on case-insensitive fs (fixes #406)

attempt to preserve PATH_INFO case even when the
URI is mapped onto a case-insensitive file system.

NTFS (Windows) is case-insensitive (even though it is case-preserving)
HFS+ (Mac OS X) can be formatted to be case-insensitive

x-ref:
"... PATH_INFO ... improperly converted to lowercase"
https://redmine.lighttpd.net/issues/406

History

#1

Updated by Anonymous almost 12 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

#2

Updated by jan almost 12 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.

#3

Updated by Anonymous about 11 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

#4

Updated by Anonymous almost 10 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

#5

Updated by Seldaek over 9 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.

#6

Updated by stbuehler over 9 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.

#7

Updated by stbuehler about 9 years ago

  • Status changed from Fixed to Wontfix
#8

Updated by gstrauss over 1 year 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) {
#9

Updated by gstrauss over 1 year 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.

#10

Updated by gstrauss over 1 year ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

Also available in: Atom