Edit report at https://bugs.php.net/bug.php?id=60850&edit=1
ID: 60850
Updated by: larue...@php.net
Reported by: dave dot marshall at atstsolutions dot co dot uk
Summary: Built in web server does not set
$_SERVER['SCRIPT_FILENAME'] when using router
Status: Closed
Type: Feature/Change Request
Package: Built-in web server
Operating System: Linux/Ubuntu 11.10
PHP Version: 5.4SVN-2012-01-23 (snap)
Assigned To: laruence
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
------------------------------------------------------------------------
[2012-03-11 09:02:26] larue...@php.net
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php
------------------------------------------------------------------------
[2012-03-11 08:56:05] larue...@php.net
Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revision&revision=324098
Log: Implemented FR #60850 (Built in web server does not set
$_SERVER['SCRIPT_FILENAME'] when using router)
------------------------------------------------------------------------
[2012-03-09 02:54:12] sam dot e dot giles at googlemail dot com
Sorry for the multiple comments..
I see what laruence was saying now about the script that has been
routed to.
After playing around some more, I see what is meant by this.
If the router returns false, then the resource is served as is, and, if it is a
PHP script, the $_SERVER['SCRIPT_FILENAME'] is set to the resource when the
dispatched script is executed. However, if we set the server variable as the
router, SCRIPT_FILENAME variable will always point to the router.
So if you were to have the following code in your router:
<?php
var_dump($_SERVER['SCRIPT_FILENAME']);
if (preg_match('/\.(?:php)$/', $_SERVER["REQUEST_URI"]))
return false; // serve the requested resource as-is.
else {
include ("test.php");
}
And in test.php you had:
<?php
var_dump($_SERVER['SCRIPT_FILENAME']);
If you request /test.php the output is:
string(43) "/home/sam/php-svn/php-src/sapi/cli/test.php"
string(43) "/home/sam/php-svn/php-src/sapi/cli/test.php"
Where as if you request / the output is:
string(45) "/home/sam/php-svn/php-src/sapi/cli/router.php"
string(45) "/home/sam/php-svn/php-src/sapi/cli/router.php"
Even though we've been routed to what is essentially test.php, it is not named
as our SCRIPT_FILENAME, which is what is desired.
It should be noted that, index code should not be placed in the router.php file
in the documentation, instead, have it served directly using `return false` OR
include it after a routing rule of some sort.
It should also be well noted the real purpose of the router script, being that
it shouldn't hold your application rules only routing rules, perhaps making it
distinguishable through a different file extension in the docs?
------------------------------------------------------------------------
[2012-03-09 02:20:12] sam dot e dot giles at googlemail dot com
Added a patch to add this functionality.
------------------------------------------------------------------------
[2012-03-09 01:31:15] sam dot e dot giles at googlemail dot com
I'm split on this issue.
On one hand for consistency I think that the $_SERVER['SCRIPT_FILENAME'] should
be set in the router script.
On the other hand, this is meant to be a test server NOT a production server,
and the router script should simply be used to route, or rewrite URL's to
another script, i.e. The router script shouldn't be used in production as is.
Either way the documentation should reflect this.
However I personally, after much thought think that $_SERVER['SCRIPT_FILENAME']
should be set, purely for consistency, after all, it is the filename of the
running script.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=60850
--
Edit this bug report at https://bugs.php.net/bug.php?id=60850&edit=1
