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

From: 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

« previous php.bugs (#189158) next »