Bug 132003 - fopen doesn't work across remote connections while under Apache
Summary: fopen doesn't work across remote connections while under Apache
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: php
Version: 3.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact: David Lawrence
URL: http://webhost3.dejazzd.com/test.php
Depends On:
Blocks: 123574
TreeView+ depends on / blocked
Reported: 2004-09-07 18:32 UTC by Daniel Fisher
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2004-12-21 18:54:52 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2004:687 high SHIPPED_LIVE Important: php security update 2004-12-21 05:00:00 UTC

Description Daniel Fisher 2004-09-07 18:32:34 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)

Description of problem:
Customer runs a very simple script:

fopen("http://webhost12.dejazzd.com/index.html", "r"); 
$httpfile  =
include 'http://webhost12.dejazzd.com/index.html'; 

Script fails with error:
'failed to open stream: HTTP request failed! '

Script runs correctly in command line, but fails when run as a script
behind Apache.

Version-Release number of selected component (if applicable):

How reproducible:
Couldn't Reproduce

Steps to Reproduce:
1. Copy script
2. Run from web

Actual Results:  Worked fine for me, customer can't get it to work.

Expected Results:  Should show the text:

Additional info:

I have spoken with Joe Orton about this:

I asked customer to recompile with '--enable-debug' (as recommended here: 
), but still had issue

Comment 1 Joe Orton 2004-09-07 18:37:38 UTC
Can you confirm whether the customer has configured httpd with a large
number of log files, and is running the server with an increased
ulimit -n?  That is key as to whether this has anything to do with the
upstream bug you reference.

Comment 2 Daniel Fisher 2004-09-07 18:40:21 UTC
The customer does indeed have a large number of logfiles and has
modified their ulimit -n.

How does this affect the prognosis/potetnial fix?

Thank you for your time,
Daniel Fisher

Comment 3 Joe Orton 2004-09-07 19:38:57 UTC
Yes, thank you, that confirms that this is problem described in the
upstream bug report.   I will make test packages available shortly
which should work around the issues reported.

Comment 4 Joe Orton 2004-09-08 10:37:09 UTC
Packages which include a workaround for this issue are available for
test purposes from the following location:


Please note that even with this workaround, there are still many
places where PHP does not correctly handle fd numbers greater than
1024 and may behave unreliably in such configurations: notably
socket_select and stream_select, also any use of the curl extension.

Comment 5 D&E Communications 2004-09-09 14:45:35 UTC
We applied the rpms last night and they seemed to fix the problem. 
Thank you all for the help.  

Is this fix going to be in future releases?

Comment 6 Joe Orton 2004-09-09 15:01:07 UTC
Thanks for testing this out.  This fix is scheduled for inclusion in a
future RHEL3 update.

Comment 7 D&E Communications 2004-09-09 15:15:56 UTC
We applied the rpms last night and they seemed to fix the problem. 
Thank you all for the help.  

Is this fix going to be in future releases?

Comment 8 D&E Communications 2004-09-09 15:17:26 UTC
Sorry I hit reload. 

Comment 9 Joe Orton 2004-09-09 15:21:47 UTC
No problem.

Comment 10 Jon Benson 2004-12-20 00:51:14 UTC
Just getting myself added so I know when the patch is released.  :)

Comment 11 Mark J. Cox 2004-12-21 18:54:52 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.