HTTP requests (file_get_contents, curl) times out when calling same server listener

[garygreen]

Description

Issue

When a script makes a HTTP call on Windows to the same host/server listener - it will time out.

Steps to reproduce:

1. Install PHP 8.2.8 for Windows
2. Create bug/test.php file with following code:

<?php
echo $_GET['say'] ?? file_get_contents('http://localhost/test.php?say=hello');

3. cd bug and start a php server in that folder: php -S localhost:80
4. Try to run the script, it will time out: php test.php

The script will time out, as the file_get_contents never responds.

Expected result

It should echo hello to the console

Further testing

This issue extends further than file_get_contents and php web server - it also affects:

• curl functions curl_exec etc not just file_get_contents
• Using php-cgi.exe and nginx on Windows with fastcgi_pass
• Also tested with Caddy web server, using proxy pass, same issue

Linux/Unix

This doesn't affect linux. Trying the above reproduction steps in Linux will echo hello. It also works as expected when using WSL/Windows Sub System for Linux.

PHP Version

PHP 8.2.8

Operating System

Windows 10

[damianwadley]

Working for me. Are you sure you're running this exactly as described: copy/paste that exact code into a file, stand up a brand new dev server without any special settings or options, and run the file its first time through the command-line?
The dev server is single-threaded, so if there is any other active request to the server, such as if you initiate the first test.php call through a browser, then it'll block.

If you're saying that nginx + php-cgi instead of the dev server demonstrates this same problem then I can tell you with a fairly high degree of certainty that you have some other problem going on here - one that isn't a bug in PHP...

[garygreen]

I did more testing and found that the issue is with FastCGI. When a request is made through FastCGI that calls the same listener, it will hang. Any subsequent calls will also hang until the FastCGI process times out - this is why I thought it was an issue with php server + php test, but it was actually locking the response until FastCGI timed out.

So the new reproducible steps (Using Caddy web server, as it's simpler to setup and test on Windows - but same problem can be found with nginx)

1. Install Caddy: https://caddyserver.com/download (just click download, no plugins needed)
2. Add this Caddyfile to the folder, tweak paths to where you've created bug/test.php:

{
	auto_https off
}

http://localhost {
	root E:/php82/bug
	php_fastcgi 127.0.0.1:9000
}

3. Listen on FastCGI binary: E:\php82\php-cgi.exe -b 127.0.0.1:9000
4. Try to access http://localhost/test.php

It will hang and timeout. If the FastCGI process is quit in the console, the page will instantly cut the connection

Tested this with both the Thread Safe and Non-thread safe PHP binaries on Windows and it has the same problem

[KapitanOczywisty]

<?php
echo $_GET['say'] ?? file_get_contents('http://localhost/test.php?say=hello');

I have strange feeling, that you created infinite recursion with this strange example, and the real problem is that query string is somehow lost.

Can you test that this is not happening here?

<?php
$hello = $_GET['say'] ?? 'nope';
file_put_contents(__DIR__ . "/test.log", date('r') . " - {$hello}\n", FILE_APPEND | LOCK_EX);
echo $_GET['say'] ?? file_get_contents('http://localhost/test.php?say=hello');

This should produce only 2 dates per request in test.log.

[garygreen]

@KapitanOczywisty Interestingly in your code example I get this in test.log:

Mon, 17 Jul 2023 14:38:57 +0000 - nope
Mon, 17 Jul 2023 14:39:57 +0000 - hello

However, it hangs for a long time between "nope" and "hello" and the request still times out to the browser. 😕

==

The same issue can be found with this example:

bug/sayhello.php

hello

bug/test.php

<?php
echo file_get_contents('http://localhost/sayhello.php');

I probably should have used that example, as it is less contrived and shows it's not a recursive issue.