|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22937 Valid http:// URL does not open with fopen()
Submitted: 2003-03-27 18:41 UTC Modified: 2003-06-11 16:12 UTC
From: freddie at bingham dot net Assigned: wez (profile)
Status: Not a bug Package: HTTP related
PHP Version: 4.3.2 OS: Redhat 7.3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
20 + 13 = ?
Subscribe to this entry?

 [2003-03-27 18:41 UTC] freddie at bingham dot net
Consider the following script:


$p = fopen('', 'rb');
$p2 = fopen('', 'rb');


Both sites are opened when using php 4.2.3 (and earier version) whereas 4.3.1 throws the following warning:

Warning: fopen( [function.fopen]: failed to create stream: HTTP request failed! in /home/juan/public_html/forums/foo.php on line 3

Considering that the second fopen() generates no warnings, fopen is working in some cases in regards to urls. Of course, Apache has been restarted numerous times with no effect.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-03-27 19:01 UTC]
Please try using this CVS snapshot:
For Windows:

Works fine here.  (using latest stable CVS)

 [2003-04-07 12:16 UTC] psvanvicat at yahoodot dot com
I have a similar problem, but my virtual host has upgraded to 4.3.1 and I can't convince them to go back to a stable snapshot...anything I can do in my scripts to fix this?  Any updates they can do?
 [2003-06-07 12:06 UTC] freddie at bingham dot net
This is still happening in the 4.3.2 release

This is the result of the above script:

Warning: fopen( failed to open stream: HTTP request failed! k? in test.php on line 3
 [2003-06-08 11:18 UTC] dunkel at calamus dot net
For me, a similar problem exists in PHP 4.1.2 (on Apache):

Take a look at, please.

In the paragraph "P&#345;?ru&#269;ka:" (Documentation:) I want to fopen() a page on a Czech server. As this page does not exist, a visible warning is been returned which should probably NOT occur here. Instead, I expect the function call to ONLY give back an invalid $fp.
 [2003-06-08 19:33 UTC]
Why shouldn't it give that error? The first url in your 
script does not exist.

 [2003-06-08 20:15 UTC] freddie at bingham dot net
It very well does exist. Perhaps you just clicked on the url as presented on this page which adds a ', to the end.
 [2003-06-09 01:29 UTC] dunkel at calamus dot net
In my problem case, the remote file does NOT exist. This is what I want to find out with fopen(). The according code looks like this:

// don't check remote files with file_exists() !!!
if ($lan == "cz")
  $file = fopen("$url_docu", "rb");
  if ($file)
    echo "<blockquote>\n";
    echo "<a href=\"$url_docu\" class=\"h4\">";
    echo " (HTML)</a>\n";
    echo "</blockquote>\n";

In fact, $file is invalid here as it should. But in no case this function call of fopen() should give a warning about this, shouldn't it?

In, you see how it works with existing remote files.

In, you can see how the result should be (refer to 'Manual' instead of the Czech 'Prirucka').
 [2003-06-09 03:17 UTC]
dunkel at calamus dot net:
fopen will raise a warning if it could not open the file.  That is how it works.  To hide the warning, use the @ operator.

freddie at bingham dot net:
please try this little script:
$p = fopen('', 'rb');

and paste the result here
 [2003-06-09 09:19 UTC] freddie at bingham dot net
Can we please stick to the bug that I have reported. Thanks.

My script works in everything before 4.3.0. What had changed to break a valid URL from being opened with fopen() and why was I told it was fixed in the PRE released 4.3.2, to only find it is still broken in 4.3.2
 [2003-06-09 09:41 UTC]

Please provide the information I requested.

$p = fopen('', 'rb');

and paste the result here.

 [2003-06-09 10:33 UTC] freddie at bingham dot net

The fact that you are asking me this implies that it works for you on 4.3.2 or you are unable to test it on 4.3.2. Is that the case?
 [2003-06-09 16:01 UTC]
I'm afraid I can verify this one, both with 4.3.2 and 4.3.3-dev as of today:

# sapi/cli/php -c php.ini-recommended -r '
$p = fopen("", "rb");
PHP Warning:  fopen( failed to open stream: HTTP request failed! ?|?c ???????? in Command line code on line 2
PHP Notice:  Undefined variable:  http_response_headers in Command line code on line 3

Configured only with --enable-debug --disable-mbstring, it's the same problem, but slightly different junk characters in the error message. Otherwise these junk characters are always the same (for the same build).
 [2003-06-09 16:12 UTC]
It looks like the web server at that address doesn't like the request headers coming in multiple packets.

Performing a strace on php shows that it is conforming to the HTTP protocol, but the remote host does not send a response (recv call returns 0).

To me, this sounds like a bug in the web server (I've never heard of SmallWebServer; anyone have any info on it?).

I'm working on a write buffer for streams that will act as a workaround for this problem, but my time is limited, so please be patient.
 [2003-06-10 14:43 UTC]
According to
<>, this "SmallWebServer" is their own software, written in SmallTalk. Google finds only pages inside the domain, so they are probably the only ones using it.
 [2003-06-10 16:13 UTC]
Try the following test:

  ini_set('user_agent', 'PHP/4.3.2');

  $p = fopen('', 'rb');
  $p2 = fopen('', 'rb');


 [2003-06-10 16:54 UTC]
Wow - this works for me, both with 4.3.2 and the same 4.3.3-dev from yesterday.

I don't have the slightest idea why this works, though. 
 [2003-06-11 16:12 UTC]
The HTTP protocol specifies User-Agent as an optional header, it also states that invalid requests should be replied to with an appropriate error message (a response code between 400 and 599).

The webserver at conforms to neither of those requirements.

PHP only sends the User-Agent header if one is provided via the php.ini option 'user_agent' (or, as of PHP 5.0.0, via one of the apropriate context options).  In this case the webserver in question is throwing out the request as invalid and providing no error data, both of which are improper behavior.

With agreement from wez I'm marking this bug bogus because PHP is behaving as it should, the webserver is not.

Suggested workaround to user:  Specify a user_agent in php.ini or via ini_set().
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Tue Jan 31 11:03:44 2023 UTC