Edit report at https://bugs.php.net/bug.php?id=60351&edit=1
ID: 60351
Updated by: cmb@php.net
Reported by: scott at aubrey dot org dot uk
Summary: Phar::createDefaultStub runs indexfile, not
webindexfile parameter
-Status: Open
+Status: Feedback
Type: Bug
Package: Built-in web server
Operating System: Mac OS X Lion 10.7.2
PHP Version: 5.4.0RC1
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
It seems to me, in this case you don't want to use test.phar as
router script. You only want to be able to execute test.phar when
requested from the web server. For Apache you'd have to configure
the respective handler, for the built-in web server you'd have to
use a router script, maybe something like the following:
<?php
$ext = pathinfo($_SERVER['SCRIPT_NAME'], PATHINFO_EXTENSION);
if ($ext == 'phar') {
include $_SERVER['SCRIPT_NAME'];
return true;
} else {
return false;
}
?>
Then the built-in web server should behave as expected.
Previous Comments:
------------------------------------------------------------------------
[2014-12-31 21:19:08] scott at aubrey dot org dot uk
forgot to say, all above tested with 5.6.3
------------------------------------------------------------------------
[2014-12-31 21:18:14] scott at aubrey dot org dot uk
@ eldmannen+php at gmail dot com
It's been a good while since I've played with this, but my test still shows
"CLI" in the output after setting up as you said.
However I can sort of get it to work how I expect by following these steps.
create the test script as original report, and run on the cli to create the phar:
php -d phar.readonly=0 test.php
run the built in server with the router script:
php -S 127.0.0.1:8080 test.phar
then visit http://127.0.0.1:8080/test.phar or http://127.0.0.1:8080/test.phar/web.php with the
built in server and you'll get "web". If you visit http://127.0.0.1:8080/, it fails again, showing "CLI".
My *guess* from this testing, and from fiddling with the default stub created, is that when
Phar::webPhar() is called from the stub, it *expects* the REQUEST_URI to begin with the phar's
filename before it will process as a web request. This is evidenced by the phar router working only
when visiting /test.phar.
The default stub expects that if Phar::webPhar() doesn't handle it, then next thing to do is
show the other, non-web script. So any other URI not starting with /test.phar shows "CLI"
even though it's run from the same web server.
It would be better if Phar::webPhar() could detect if it's been run from a web context some
other way. Maybe if $_SERVER['REQUEST_URI'] is set at all, or even just where
php_sapi_name() !== "cli"? Any other ideas?
As an example, if you replace the default stub with this:
<?php
Phar::interceptFileFuncs();
set_include_path('phar://' . __FILE__ . PATH_SEPARATOR . get_include_path());
if (php_sapi_name() === "cli") {
include 'phar://' . __FILE__ . '/' . 'cli.php';
return;
}
include 'phar://' . __FILE__ . '/' . 'web.php';
return;
__HALT_COMPILER();
?>
it works as a router script, and from the CLI, showing "web" and "CLI"
respectively.
------------------------------------------------------------------------
[2014-12-23 16:14:22] eldmannen+php at gmail dot com
You can run the PHAR on the PHP built-in web server using a normal PHP file that does an include.
$ php -S 0.0.0.0:8000
<?php
require 'foo.phar';
------------------------------------------------------------------------
[2011-12-06 20:38:48] scott at aubrey dot org dot uk
That may be what is happening, but It's not what I would expect, nor what the
documentation says:
"The script is run at the start of each HTTP request. If this script returns
FALSE, then the requested resource is returned as-is. Otherwise the script's
output is returned to the browser."
http://php.net/manual/en/features.commandline.webserver.php
So from that description, I would expect the router scripts output to return the
resource. Using a phar, I would expect the stub to setup the phar for web, and
using the .phar format default stub I would expect the second argument to do that
correctly?
Unless I'm way off with my expectations here.
------------------------------------------------------------------------
[2011-12-06 16:58:52] reeze dot xia at gmail dot com
Hi, scott:
I got your idea, you use phar file as router script. by look into the builtin
server. the route script is a simple script executed before server decide whether
to server the php page or not. so In my opinion, the router file is **INDEED** run
in cli mode instead of web mode. so the behavior is expected ;-)
So I think this bug can change to Not Bug, what do you think?
------------------------------------------------------------------------
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=60351
--
Edit this bug report at https://bugs.php.net/bug.php?id=60351&edit=1