|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52322 webPhar acting like not running in webpage
Submitted: 2010-07-12 23:03 UTC Modified: 2020-06-25 08:44 UTC
Avg. Score:3.4 ± 0.7
Reproduced:5 of 6 (83.3%)
Same Version:0 (0.0%)
Same OS:1 (20.0%)
From: myselfasunder at gmail dot com Assigned: bishop (profile)
Status: Assigned Package: PHAR related
PHP Version: 5.2.13 OS: *
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2010-07-12 23:03 UTC] myselfasunder at gmail dot com
I'm using an Apache alias to map "/" to my Phar, and the webPhar() call acts as if it was run from the CLI.

Test script:
My setStub() call looks like:

Phar::webPhar("TestPhar.phar", "TestPhar/index.php");
echo "I am intended to be executed from a web browser: " . php_sapi_name() . "\n";
exit -1;

Apache's alias:

  Alias / C:/Development/webdir/vhosts/phartest/TestPhar.phar

Expected result:
"I am index."

Actual result:
I am intended to be executed from a web browser: apache2handler

(*notice that PHP still recognizes that we're running under Apache. Why doesn't webPhar()?)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-01-22 01:58 UTC] panman at traileyes dot com
I noticed that you listed the PHP version as 5.2.13. The Phar::webPhar() wasn't introduced until PHP 5.3.
 [2011-01-22 06:44 UTC] myselfasunder at gmail dot com
My current system is PHP 5.2.12 under Windows 7. Taking the PECL package from 
5.2.6 (because that's the most recent available for 5.2.12), and using the Phar 
module, I've executed the following:

  var_dump(preg_grep('/web/i', get_class_methods('Phar')));

and got the following matching methods:

  array(2) {
    string(7) "webPhar"
    string(7) "webPhar"

Therefore, not only is it available under 5.2.12, it must be available under 
5.2.6 as well.

Do you have an actual response to the bug report?

 [2013-02-07 17:21 UTC] andycbriggs at gmail dot com
I'm also seeing this bug whilst running Apache.

However I'm using: 

$phar->setDefaultStub('cli/console.php', 'web/web.php');

I noticed in the default stub of the phar is the line:
if (@(isset($_SERVER['REQUEST_URI']) && isset($_SERVER['REQUEST_METHOD']) && 

If I echo those from console.php I see they are set and that line should pass.

Also makes me point to Phar::webPhar

Tested on PHP 5.4.11, 5.3.21, 5.2.17
The phar was recreated under each version also.
 [2014-03-21 20:46 UTC]
I have this problem using PHP 5.4.4 (debian) via CGI on Lighttpd.
 [2014-04-14 04:09 UTC]
I'm afraid I am not bitten by this bug but rather by bug #67071.
 [2014-04-14 04:20 UTC] myselfasunder at gmail dot com
Feel free to comment on that bug.
 [2016-05-29 10:33 UTC] f dot hazard at sowapps dot com
I am experiencing the same issue and I dont understand why this is not working.

I am including it in an index.php file with
require_once 'myapp.phar';
The is clearly redirecting me to the CLI interface if I try to access it from a browser.

I am currently building the PHAR with php5.5.12 under Windows 10 and running it using 5.6.21-1~dotdeb+7.1.
 [2017-05-04 11:07 UTC]
The same issue can be observed by symlinking a .phar file, see bug #67071.

Reason for this behavior is that Phar::webPhar() tries to extract the path after the .phar filename so that it can do the mapping.
When accessing /test.phar/foo.css, it looks for "test.phar" and then uses "/foo.css" as path of the file that shall be extracted.

If the file name "test.phar" (zend_get_executed_filename()) cannot be found within SCRIPT_NAME (cgi) or REQUEST_URI (non-cgi), it does not know how to continue and returns:

> /* this can happen with rewrite rules - and we have no idea what to do then, so return */
 [2019-02-08 20:42 UTC]
-Assigned To: +Assigned To: bishop
 [2020-06-25 08:44 UTC]
-Operating System: Windows 7 +Operating System: *
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Tue Nov 28 13:01:27 2023 UTC