Bug #406

PHP SCRIPT_NAME, PATH_INFO, PHP_SELF and others improperly converted to lowercase

Added by Anonymous over 4 years ago. Updated almost 2 years ago.

Status:Wontfix Start:
Priority:Normal Due date:
Assigned to:- % Done:

0%
Category:core
Target version:-
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

History

Updated by Anonymous over 4 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 over 4 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 4 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 2 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 2 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 2 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 stbuehler almost 2 years ago

  • Status changed from Fixed to Wontfix

Also available in: Atom