php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #27111 virtual() function does not behave as documented
Submitted: 2004-01-31 21:06 UTC Modified: 2004-08-17 10:01 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: e-phpbug at erowid dot org Assigned: vrana (profile)
Status: Closed Package: Documentation problem
PHP Version: 4.3.4 OS: freebsd
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: e-phpbug at erowid dot org
New email:
PHP Version: OS:

 

 [2004-01-31 21:06 UTC] e-phpbug at erowid dot org
Description:
------------
Documentation for virtual() claims that it should work like an apache sub-request like the shtml #include virtual command.

It does not.

Bug 26500 is reporting the same bug but appears to have been closed by someone who does not understand the issue.  

It is clear that it is not doing this as advertised for php scripts.  What should be creating an http request is instead clearly short-circuting to a PHP include() call with the docroot pre-pended when the target is a php script.  

This results in any CGI PHP called through virtual being called as a sub-component of the current PHP script instead of as its own execution, with its own environment, own POST/GET variables, etc. 

This clearly violates the documented purpose of the call (to replicate the apache shtml functionality).

Also, as a side effect of how this behaves, virtual changes the cwd in the calling script (a behaviour that should not happen with an apache subrequest).

Both of these problems are solved if http://www.host.com/ is pre-pended to the string and passed to include() instead, which actually generates an http sub-request.

Proposed solutions:
1) change the documentation so that it doesn't claim this is the same as apache's include-virtual directive.

2) fix the problem since this is clearly the intended behaviour for the function.

Reproduce code:
---------------
The following should have equivalent effect, given the documentation:

<!--#include virtual="/path/to/stuff.php?Var=Value"-->

and

<? virtual("/path/to/stuff.php?Var=Value"); ?>


with stuff.php as:

<? $Var = $_GET['Value'];  print "Var: $Var <br>\n"; ?>



Expected result:
----------------
The shtml results in:

Var: Value <br>



Actual result:
--------------
the php results in:

PHP warnings (if you E_ALL set)
Var:  <br>

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-07-27 22:33 UTC] vrana@php.net
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

Copied from sources: "This function works only when PHP is compiled as an Apache module, since it uses the Apache API for doing sub requests."
 [2004-07-28 07:50 UTC] e-phpbug at erowid dot org
It seems you continue to not understand the problem? Did you try it?  Do you realize this exact bug has been closed improperly before?

No, simply noting that it only works when compiled as an apache module does not solve the problem.  The function does not work as documented no matter how PHP 4.x is compiled.  I have not tried PHP5, but given your response to the problems, it seems very very unlikely its been fixed.

Did you try my simple test case?  Can you get the same behaviour from shtml include virtual on apache as you do from PHP?  Also please check your apache log files.  No additional request to apache is being generated, query parameters don't get passed and the environment is wrong.  This function does not work when used to include PHP files, otherwise it works fine.


The documentation should be changed to say something more like:

"Note: This function does not perform like apache's include virtual shtml directive when used to call another PHP file.   virtual() does not call the apache httpd, but instead runs the script internally without generating another file hit. It does not properly pass any query parameters or environment variables to the called php file."

I would guess the problem is with some code above the apache API call and PHP is being "smart" by seeing its a php file and short circuiting instead of actually calling apache.  Or there is a bug between apache and PHP, but its not getting to apache as a file request, its just getting executed by the PHP module internally.

Whatever the cause, however, your proposed resolution, is wrong.
 [2004-07-28 10:04 UTC] vrana@php.net
Yes, I tried it.

It seems that this function works as expected only with Apache 2. I tried these simple scripts:

main.php: <?php virtual("virtual.php?a=c"); ?>
virtual.php: <?php echo $_SERVER["QUERY_STRING"]; ?>

Apache 1: Parameters of main.php are printed
Apache 2: "a=c" is printed

virtual.php is not listed in Apache access log in either case.

It's independent if you use PHP 4 or PHP 5. I tried it under Windows.

Do you agree with this description?
 [2004-07-28 21:36 UTC] e-phpbug at erowid dot org
Yes, excellent.  I do not have access to a properly-functioning apache2+mod_php setup, so I can't test this myself, but I'd say you've hit the nail on the head.

Thanks for taking another look at it!  Your work on this is very much appreciated.
 [2004-08-17 10:01 UTC] vrana@php.net
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jun 02 12:01:30 2024 UTC