Fix #60471: Solution for "Invalid request (Unexpected EOF)" message in built-in web server

[SammyK]

Possible solution to bug #60471.

The built-in web server generates a lot of confusing Invalid request (Unexpected EOF) error messages when using a browser that supports preconnect like Firefox or Chrome.

In addition, Chrome uses a predictive TCP preconnect technique to speed up the request time. This means that for nearly every connection to a web server, Chrome will open more than one TCP connection as you can see here.

In this case, the first connection (50685) was used for the actual request while the other one (50686) waits for a request for some other resource (like a favicon or whatever). You can see it hanging open when looking at the TCP connections with nettop (on Mac).

After a timeout (usually about 10 seconds) the Invalid request (Unexpected EOF) message is output from the PHP CLI web server. This error message is confusing to developers everywhere. So developers think they did something wrong and spend a lot of time looking for answers only to be greeted with lots of misinformation like "just add a favicon".

Since preconnecting is starting to become a common practice with modern web browsers, this PR offers a possible solution by changing the behavior of the built-in web server in the following ways:

1. Display the useful debug messages about opening and closing the TCP connections by checking PHP_DEBUG instead of DEBUG so we see them when using the --enable-debug flag. (I don't know where DEBUG came from).
2. Change the unhelpful Invalid request (Unexpected EOF) message to Closed without sending a request; it was probably just a preconnect so that a quick Google search for "preconnect" will explain all the things.
3. Move the new message to display only at the debug level since it's an expected behavior from modern browsers. This will prevent any future confusion since it's not an error.

The new output for closed TCP preconnections in debug mode would look like this.

Phew. I hope this clarifies things for everyone who has been pulling their hair out with this! :)

[sgolemon]

Repeating what I just told you in person. :D

This PR incorrectly assumes that a request will always come in as a single packet. However, if a client connects to the webserver, sends a packet, THEN disconnects (see repro below) then the same recv==0 state will be triggered and mistaken for an ababdoned optimistic connection.

Try taking a look at client->parser.state to verify that it's in s_start_req state. If that is true AND recv == 0, then we can safely call it an abandoned optimistic connection. Otherwise we still want to raise a warning that a partial connection was abandoned.

$sock = fsockopen('127.0.0.1', $whateverport);
fwrite($sock, "HEAD / HTTP/1.0\r\n");
fclose($sock);

[SammyK]

Done & done! :)

The web server now correctly identifies the difference between an actual unexpected EOF vs a preconnection and shows the correct message. I didn't see any infrastructure to add automated tests to the web server, but here's the code I used to test it:

<?php

const HOSTNAME = 'localhost';
const PORT = '8888';
const BASE_URL = 'http://'.HOSTNAME.':'.PORT;

echo "PHP's built-in webserver test...\n";

# Normal request
file_get_contents(BASE_URL.'/phpinfo.php');

# Partial HTTP request
$sock = fsockopen(HOSTNAME, PORT);
fwrite($sock, "HEAD / HTTP/1.0\r\n");
fclose($sock);

# Non-HTTP request
$sock = fsockopen(HOSTNAME, PORT);
fwrite($sock, "POOP!");
fclose($sock);

# Mimmik a preconnect
$sock = fsockopen(HOSTNAME, PORT);
fclose($sock);

I received the following results as expected:

[php-pulls]

Comment on behalf of pollita at php.net:

Pushed as fd0e71d