php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #60850 Built in web server does not set $_SERVER['SCRIPT_FILENAME'] when using router
Submitted: 2012-01-23 13:45 UTC Modified: 2012-03-11 09:02 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: dave dot marshall at atstsolutions dot co dot uk Assigned: laruence (profile)
Status: Closed Package: Built-in web server
PHP Version: 5.4SVN-2012-01-23 (snap) OS: Linux/Ubuntu 11.10
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: dave dot marshall at atstsolutions dot co dot uk
New email:
PHP Version: OS:

 

 [2012-01-23 13:45 UTC] dave dot marshall at atstsolutions dot co dot uk
Description:
------------
Nothing special done when compiling, just --configure and then make.

If the webserver couldn't do any path translation, $_SERVER['SCRIPT_FILENAME'] is not populated. If this is desired behaviour, perhaps the documentation should be updated, as existing software will rely on it.

----

Given the code below in router.php, and starting the web server with a router
> ~/Downloads/php5.4-201201231230/sapi/cli/php -S localhost:8000 router.php

Fetch the root url, NULL returned

> curl localhost:8000
NULL

Given that this variable is documented, I'd expect it to be string(29) "/home/davem/temp_ws/router.php"

Touching a file called index.php, seems to trick the webserver in to thinking it's done a path translation for the root url

> touch index.php
> curl localhost:8000
string(29) "/home/davem/temp_ws/index.php"



Test script:
---------------
router.php

<?php
var_dump($_SERVER['SCRIPT_FILENAME']);
return true;



Expected result:
----------------
string(29) "/home/davem/temp_ws/router.php"

Actual result:
--------------
NULL

Patches

add_router_script_file_name_svr_var (last revision 2012-03-09 02:19 UTC by sam dot e dot giles at googlemail dot com)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-01-24 02:56 UTC] laruence@php.net
-Type: Bug +Type: Feature/Change Request
 [2012-01-24 02:56 UTC] laruence@php.net
router is a especially script, if we set this as the script_name, what about the 
script which router routed to?
 [2012-01-24 10:15 UTC] dave dot marshall at atstsolutions dot co dot uk
I appreciate that, but that assumes the router will route to another script on disk, rather than loading the required code and generating a response like most of the MVC frameworks do.
 [2012-03-09 01:31 UTC] 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.
 [2012-03-09 02:20 UTC] sam dot e dot giles at googlemail dot com
Added a patch to add this functionality.
 [2012-03-09 02:54 UTC] 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-11 08:56 UTC] laruence@php.net
Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=324098
Log: Implemented FR #60850 (Built in web server does not set $_SERVER['SCRIPT_FILENAME'] when using router)
 [2012-03-11 09:02 UTC] laruence@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 09:02 UTC] laruence@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: laruence
 [2012-03-11 09:02 UTC] laruence@php.net
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.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 07 20:01:27 2024 UTC