Ticket #406 (assigned defect)

Opened 3 years ago

Last modified 4 months ago

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

Reported by: lighttpd-2005@ryandesign.com Assigned to: anonymous (accepted)
Priority: normal Milestone:
Component: core Version: 1.4.
Severity: major Keywords:
Cc: Blocking:
Need Feedback: 0

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:

<pre><?php print_r($_SERVER); ?></pre>

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.

Attachments

isd.jpg (152.3 kB) - added by anonymous on 09/21/2007 07:27:08 AM.

Change History

01/02/2006 06:08:34 PM changed by me@aaronsw.com

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.

01/04/2006 10:57:12 AM changed by jan

  • owner changed from jan to anonymous.
  • status changed from new to assigned.
  • version changed from 1.4. to 1.4..

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.

11/29/2006 01:11:49 AM changed by brion@pobox.com

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?

09/21/2007 07:27:08 AM changed by anonymous

  • attachment isd.jpg added.

03/04/2008 01:50:33 AM changed by hugues.lismonde@gmail.com

  • blocking changed.
  • pending changed.

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.

03/28/2008 11:22:23 PM changed by Seldaek

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.

Add/Change #406 (PHP SCRIPT_NAME, PATH_INFO, PHP_SELF and others improperly converted to lowercase)




Change Properties