ID: 22526 Comment by: jules at acris dot co dot uk Reported By: iberry at raxnet dot net Status: Closed Bug Type: Session related Operating System: Windows 2000 PHP Version: 4CVS, 5CVS New Comment:
I've experience what appears to be the same bug when using file("http://blah") to retrieve the contents of a particular URL. The workaround suggested does do the job. FWIW, I'm on Linux, not Win2K, using Apache 1.x SAPI. Has this bug been fixed properly (i.e., not just the workaround suggested)? And if so, in which release? Previous Comments: ------------------------------------------------------------------------ [2004-08-19 20:25:45] jaccoh at infogateway dot org forget my last entry.. the servers are behind loadbalancers in a NAT network.. duh :) ------------------------------------------------------------------------ [2004-08-19 18:56:23] jaccoh at infogateway dot org pubnelle is right. I tried this: ----file1.php---- <? include("http://www.infogateway.org/file2.php?foo=test"); ?> ----end---- ----file2.php---- <? echo $_GET['foo']; ?> ----end---- And it crashes! Don't go tell us it is not a bug or problem, the php manual says it should work: ---- If "URL fopen wrappers" are enabled in PHP (which they are in the default configuration), you can specify the file to be included using a URL (via HTTP or other supported wrapper - see Appendix L for a list of protocols) instead of a local pathname. If the target server interprets the target file as PHP code, variables may be passed to the included file using a URL request string as used with HTTP GET. This is not strictly speaking the same thing as including the file and having it inherit the parent file's variable scope; the script is actually being run on the remote server and the result is then being included into the local script. ---- -Jacco ------------------------------------------------------------------------ [2004-08-19 17:25:24] pubnelle at megaphone dot ch Hi, I have written already about apache hanging, in bug number 28856. I think that the problem is not only session related, and that it appeared after PHP 4.3.2. You may not agree with the fact that including, requiring or "virtual"ing pages that are on the same server need to be included using the full http domain name. But there, we do it a lot, and it's working very well on our old servers, with php 4.3.2. Here is a very simple example where the server is hanging. file1.php : <? include("http://thisdomain.com/file2.php"); ?> file2.php : <? //anything, for example phpinfo(); ?> On a Debian Box, PHP Version 5.0.1-dotdeb, Apache/1.3.26, the server is hanging . No session started, session.auto_start set to Off. I agree that this is a stupid example and that here I would use simply include("file2.php"); believe me the situations where we use the include("http ...) are a lot more complex and we cannot avoid to do this. Please, don't answer that nobody uses the include, or require, or anthing, with the http to be able to use some Apache Vhost related features : we do a lot, and I am in a despair, here ... Thanks for your attention, Estelle ------------------------------------------------------------------------ [2004-07-06 21:41:22] kalvinb602 at hotmail dot com Just posting to suggest that it would be nice to have this workaround posted in the manual for popen and other system command issuing functions. I resorted to blanking out the page to keep users from clicking a second link before the first finished loading to avoid a server hang. This workaround eliminates the need for that very clunky "fix" but it took me quite awhile to find it because I was digging through the manual. It might be a good idea to link the manual entries to the related bug reports. I'm using Apache 2.0.49 PHP 4.3.6 (upgrading soon) and Windows 2000 Pro. ------------------------------------------------------------------------ [2004-03-05 02:34:26] iberry at raxnet dot net The workaround has shown to be effective in eliminating this issue. Closing the bug. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/22526 -- Edit this bug report at http://bugs.php.net/?id=22526&edit=1