Bug #60351 [Com]: Phar::createDefaultStub runs indexfile, not webindexfile parameter
| From: | eldmannen+php at gmail dot com | Date: | Tue, 23 Dec 2014 16:14:23 +0000 |
| Subject: | Bug #60351 [Com]: Phar::createDefaultStub runs indexfile, not webindexfile parameter | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-189158@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=60351&edit=1
ID: 60351
Comment by: eldmannen+php at gmail dot com
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:
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';
Previous Comments:
------------------------------------------------------------------------
[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 :)
------------------------------------------------------------------------
[2011-11-21 20:32:20] scott at aubrey dot org dot uk
Description:
------------
When building a phar, you can use a default stub creator by using
Phar::createDefaultStub. The first param should run from the CLI, the second from
a web server.
When using the built in CLI-web server and navigating to the phar, the file in
the first param is run. When testing on apache the same file, it runs the second
param.
Test script:
---------------
<?php
$testPhar = new Phar('test.phar',null, 'test');
$testPhar->addFromString('cli.php', '<?php print
"CLI".PHP_EOL;exit;');
$testPhar->addFromString('web.php', '<?php print
"web".PHP_EOL;exit;');
$testPhar->setStub($testPhar->createDefaultStub('cli.php','web.php'));
Expected result:
----------------
browser should simple output "web"
Actual result:
--------------
browser shows "CLI" when run from CLI web server
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=60351&edit=1