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

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: Assigned +Status: Open Type: Bug Package: Built-in web server Operating System: Mac OS X Lion 10.7.2 PHP Version: 5.4.0RC1 -Assigned To: cmb +Assigned To: Block user comment: N Private report: N New Comment: I still didn't find the time to have a closer look at this issue, and most likely won't in the near future, so I'm leaving that for somebody else. Sorry. Previous Comments: ------------------------------------------------------------------------ [2015-09-09 19:23:13] scott at aubrey dot org dot uk Hi That's just a slight variation on the example given by eldmannen. The reason I even tried it in the first place was because I was looking for an easy way to run tests against a phar'd application. Rather than fire up apache, or indeed have an additional route script file, it felt like a really neat trick (with the then new dev server) would be to: ./buildPhar.sh # Build the Phar file php -S localhost:8888 app.phar& # run server with phar phpunit tests/acceptance # run tests kill $! # kill BG server *I* expected that to work, but it didn't. I personally think being able to just run a phar without additional supporting files is a useful feature, and should be part of the default stub. I've since abandoned using phars to create distributable application anyway However, I still think it's weird when using the default stub and run as a router php -S localhost:8888 app.phar a request to '/' shows the CLI stub script, but a request to '/app.phar' shows the web one. Other supporting evidence: * no other files are served outside the phar, so it's *not* mapping the URL to the phar file, * running the phar from any directory (php -S localhost:8080 /path/somewhere/else/test.phar) will only show "web" when the URL start with "/test.phar", paths not required. * you can craft a trivial replacement phar stub that *does* work how I expect. It just feels like the default one not doing this is ... well, a bit buggy. If no-one else finds that at least slightly odd and a bit of a gotcha, fine. I'm not going to use it anyway, and if I was, I'd just work around it by not using the default stub. I guess I'm saying: nearly 4 years on, if no one else cares about the first impression of a phar on the dev server, I'm not going to continue arguing for it to change. ------------------------------------------------------------------------ [2015-09-09 15:14:51] cmb@php.net 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. ------------------------------------------------------------------------ [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'; ------------------------------------------------------------------------ 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