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

There was a fix for a problem in the HTTP reader that went into CVS last night; please try a stable snapshot and let us know if this problem is fixed for you.

I've tried the latest stable windows release (4.3.2-dev) on System 1, but with the same results.

By the way. I must have been a little tired when writing about the symtoms from system 1 and 2. They are instead like this:

No matter what the maximum PHP execution time is set to, the script is running in 2 minutes before it stops and writes:

Fatal error: Maximum execution time of 5 seconds exceeded in C:\wwwroot\test\readfile\read.php on line 3

In this example the max PHP execution time is set to 5 sec, but first after 2 min the script stops. The Apache timeout is set to 300 sec (5 min).

For some reason I found that it is not always that the webservers error log contain any information about the event. But when it does it looks like this:

[Wed Feb 19 16:14:31 2003] [error] [client 127.0.0.1] Premature end of script headers: php.exe

With Apache 2.0.43 and Windows I've tested this on the following PHP versions:
4.2.3      No output to the browser, Internal Server Error
4.3.0      Error message outputted to browser after 2 min
4.3.1      Error message outputted to browser after 2 min
4.3.2-dev  Error message outputted to browser after 2 min

/watson

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


And check that your php.ini has this setting:
default_socket_timeout = 60

If not, add it and try again..

Forget getting newer snapshot, just try adjusting that 
php.ini directive..

When setting default_socket_timeout to...
5  the script runs in  10
10 the script runs in  20
60 the script runs in 120

With all of the above the script still ends up showing:

Fatal error: Maximum execution time of 5 seconds exceeded in C:\wwwroot\test\readfile\read.php on line 3

...when trying to read a file from a URL.

Your system has determined two alternative addresses to attempt to contact for localhost and it attempts each alternative for default_socket_timeout in seconds.

For some reason it is not connecting successfully.
Please try the following script:
<?php
set_time_limit(600);
ini_set('default_socket_timeout', 5);
$x = file("http://localhost/test.txt");
var_dump($x);
var_dump($http_response_header);
?>

and report back here.
It would also help if you could try fetching the same url using:

curl -i http://localhost/test.txt

and paste the output here.

The script supplied gives the right output, but still takes "default_socket_timeout * 2" seconds. I found that if I removed the first line "set_time_limit(600);" the script faild again - Still I could not get rid of the long timeout.

The output from the code was:
--------------------------------------------------
array(1) {
  [0]=>
  string(6) "foobar"
}
array(9) {
  [0]=>
  string(15) "HTTP/1.1 200 OK"
  [1]=>
  string(35) "Date: Fri, 21 Feb 2003 00:43:31 GMT"
  [2]=>
  string(29) "Server: Apache/2.0.43 (Win32)"
  [3]=>
  string(44) "Last-Modified: Tue, 18 Feb 2003 15:48:22 GMT"
  [4]=>
  string(23) "ETag: "37a6-6-d5528ab3""
  [5]=>
  string(20) "Accept-Ranges: bytes"
  [6]=>
  string(17) "Content-Length: 6"
  [7]=>
  string(17) "Connection: close"
  [8]=>
  string(44) "Content-Type: text/plain; charset=ISO-8859-1"
}
--------------------------------------------------

The output from the curl command (had to install Cygwin) was:
--------------------------------------------------
$ curl -i http://localhost/test/readfile/test.txt
HTTP/1.1 200 OK
Date: Fri, 21 Feb 2003 00:41:16 GMT
Server: Apache/2.0.43 (Win32)
Last-Modified: Tue, 18 Feb 2003 15:48:22 GMT
ETag: "37a6-6-d5528ab3"
Accept-Ranges: bytes
Content-Length: 6
Content-Type: text/plain; charset=ISO-8859-1

foobar
--------------------------------------------------

I did a little test to try to find out when the script fails. It looks like the script fails everytime the "max_execution_time" is smaller than "2 * default_socket_timeout".

max_execution_time  default_socket_timeout  output
------------------------------------------------------
60                  10                      no error
25                  10                      no error
22                  10                      no error
21                  10                      no error
20                  10                      error
15                  10                      error
10                  10                      error
 5                  10                      error

(when I write "no error" the script still runs for "2 * default_socket_timeout" seconds though)

wez@php.net writes:
"Your system has determined two alternative addresses to attempt to contact for localhost and it attempts each alternative for default_socket_timeout in seconds."

I'm not into how the file() function tries to read an URL, but after what wez@php.net writes it seems that it tries a couple of different methods for reading the URL if the previous ones does not work. For me it looks like the first 2 does not work, but the 3th does.

If that is right it then makes sense that the "max_execution_time" has to be larger than "2 * default_socket_timeout" (because the first two tries have to time out fist)..

Can you try using "127.0.0.1" instead of "localhost" in your script?
If that fixes it for you, I will add equivalent code into the PHP core itself (when running under windows).

Could you also paste the output of this script:

<?php
var_dump(gethostbynamel("localhost"));
?>

Using 127.0.0.1 instead of localhost had no effect. The script still took "2 * default_socket_timeout" seconds.

The var_dump(gethostbynamel("localhost")); returned (with no delay):
--------------------------------------------------------
array(1) {
  [0]=>
  string(9) "127.0.0.1"
}
--------------------------------------------------------

Are you sure that you have your DNS (client) settings correct on the windows machine(s)?
eg: multiple entries for localhost in the hosts file, or multiple domains to auto-search when a suffix is missing configured in your DNS server (if you have one)?

It doesn't make sense for PHP to attempt multiple addresses when it can only detect a single address.

Is there any chance you can try apache 1.3.x on one of the windows servers to see if that has an effect?

I have tried 3 different addresses:
 localhost
 127.0.0.1
 www.the-real-domain.com

...all with the same result. Further more I have tried this on 3 different machines (two Windows XP and one Windows 2000 - some even on different networks).

The thing with Apache 1.3.x vs. Apache 2.x have crossed my mind as I wrote earlier. I'll try to install Apache 1.3.x and return with the results here asap.

Hi... I'm back :)

I tried the script on a Windows XP sp1 running Apache 1.3.43 and PHP 4.3.2-dev. There was no errors at all. So it has something to do with Apache 2.x and PHP.

Reclassified tas Apache2 related bug.

oops..forgot to ask: Are you using the CGI binary or the apache2 module?

CGI binary

I have added this to my httpd.conf:
----------------------------------------------
DirectoryIndex index.html index.html.var index.php
ScriptAlias /php/ "c:/php/"
AddType application/x-httpd-php .php 
AddType application/x-httpd-php-source .phps
Action application/x-httpd-php "/php/php.exe"

And what about php.ini? Have you set the settings required
for IIS in it?

oops..forget my last comment, wrong bug report.

Please check this page:
http://www.experts-exchange.com/Web/Web_Servers/Apache/Q_20396513.html

I think this is just configuration error..you're mixing
the module configuration with CGI configuration..

Back... Sorry for the delay :)

I have looked around to find out how to setup Apache 2.x to use PHP. I do think that I do it right. Take a look at:
http://dk.php.net/manual/en/install.apache2.php#install.apache2.windows

But let me know if I am wrong.

Anyway. I saw that a new version of Apache was released (v2.0.44) and tried this one - And it actually seems to work! I will just try this on one other installation tomorrow before I will say that upgrading Apache solves the problem. So don't close it yet.

keep at "Feedback" status until that then..

Yes... Upgrading to Apache 2.0.44 solves the problem. Don't know if it was Apaches problem the whole time, or it was/is the mixture of PHP and Apache that creates the problem.

/watson