Bug #60351 [Opn]: Phar::createDefaultStub runs indexfile, not webindexfile parameter

Edit report at https://bugs.php.net/bug.php?id=60351&edit=1 ID: 60351 User updated by: scott at aubrey dot org dot uk Reported by: scott at aubrey dot org dot uk Summary: Phar::createDefaultStub runs indexfile, not webindexfile parameter Status: Open Type: Bug Package: Built-in web server Operating System: Mac OS X Lion 10.7.2 PHP Version: 5.4.0RC1 Block user comment: N Private report: N New Comment: @ 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. Previous Comments: ------------------------------------------------------------------------ [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? ------------------------------------------------------------------------ [2011-11-28 20:07:09] scott at aubrey dot org dot uk Sorry, I hadn't tried it the way you had, and it does indeed work. But using the phar as the router script is the method I was using, as per http://php.net/manual/en/features.commandline.webserver.php#example-361 This does fail as described, even with a phar ending .php. ------------------------------------------------------------------------ [2011-11-28 17:39:42] reeze dot xia at gmail dot com Hi, scott: 1. How can you run .phar file in builtin web server? The server seems can only serve .php file as script file. do you mean rename the .phar file to php ? 2. After rename the phar file to php doesn't reproduce the wrong error output. Could you please post more details about the bug ? thx :) ------------------------------------------------------------------------ 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