php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #52322 webPhar acting like not running in webpage
Submitted: 2010-07-12 23:03 UTC Modified: 2020-06-25 08:44 UTC
Votes:7
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
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: myselfasunder at gmail dot com
New email:
PHP Version: OS:

 

 [2010-07-12 23:03 UTC] myselfasunder at gmail dot com 
Description:
------------
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->setStub('<?php
Phar::interceptFileFuncs();
Phar::webPhar("TestPhar.phar", "TestPhar/index.php");
echo "I am intended to be executed from a web browser: " . php_sapi_name() . "\n";
exit -1;
__HALT_COMPILER();
');

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()?)

Patches

Pull Requests

History

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.

http://www.php.net/manual/en/phar.webphar.php
 [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) {
    [54]=>
    string(7) "webPhar"
    [125]=>
    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?


Dustin
 [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']) && 
($_SERVER['REQUEST_METHOD'] == 'GET' || $_SERVER['REQUEST_METHOD'] == 'POST'))

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] cweiske@php.net 
I have this problem using PHP 5.4.4 (debian) via CGI on Lighttpd.
 [2014-04-14 04:09 UTC] cweiske@php.net 
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:02 UTC] cweiske@php.net 
Related To: Bug #67071
 [2017-05-04 11:07 UTC] cweiske@php.net 
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] bishop@php.net
-Assigned To: +Assigned To: bishop
 [2020-06-25 08:44 UTC] cmb@php.net
-Operating System: Windows 7 +Operating System: *
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 11:01:29 2024 UTC