Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Works fine here.  (using latest stable CVS)

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?

This is still happening in the 4.3.2 release

This is the result of the above script:

Warning: fopen(http://pub133.ezboard.com/bonesixthwarriors): failed to open stream: HTTP request failed! k? in test.php on line 3

For me, a similar problem exists in PHP 4.1.2 (on Apache):

Take a look at http://www.calamus.net/cz/modules/wmf.php, please.

In the paragraph "Př?ruč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.

Why shouldn't it give that error? The first url in your 
script does not exist.

It very well does exist. Perhaps you just clicked on the url as presented on this page which adds a ', to the end.

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\">";
    $this->echo_name($lan);
    echo " (HTML)</a>\n";
    echo "</blockquote>\n";
    fclose($file);
  }
  else
  [...]
}

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 http://www.calamus.net/cz/modules/aln.php, you see how it works with existing remote files.

In http://www.calamus.net/us/modules/aln.php, you can see how the result should be (refer to 'Manual' instead of the Czech 'Prirucka').

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('http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);

and paste the result here

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

*sigh*

Please provide the information I requested.

<?php
$p = fopen('http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);
?>

and paste the result here.

NULL

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?

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("http://pub133.ezboard.com/bonesixthwarriors", "rb");
var_dump($http_response_headers);
'
PHP Warning:  fopen(http://pub133.ezboard.com/bonesixthwarriors): 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
NULL
# 

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).

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.

According to
<http://www.ezboard.com/corporate/pressroom/inthenews_enterpriselinux.html>, this "SmallWebServer" is their own software, written in SmallTalk. Google finds only pages inside the ezboard.com domain, so they are probably the only ones using it.

Try the following test:

<?php
  ini_set('user_agent', 'PHP/4.3.2');

  $p = fopen('http://pub133.ezboard.com/bonesixthwarriors', 'rb');
  $p2 = fopen('http://www.microsoft.com', 'rb');

?>

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. 

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 pub133.ezboard.com 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().