Proposal: Increase cURL timeout to 60s

Hello community,

Proposal: Increase the default cURL timeout to 60 seconds.

Why?

• The current default timeout of 5s (e.g., https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-http-curl.php#L76) is not practical for most real-world applications.
• Another problem observed when moving to 6.4.2:

PHP Fatal error: Uncaught WpOrg\Requests\Exception: cURL error 28: Operation timed out after 1000 milliseconds with 0 bytes received in /opt/bitnami/wordpress/wp-includes/Requests/src/Transport/Curl.php:490

• The majority of APIs do not open their HTTP Output Stream until it is time to respond, so the 5s timeout is a bit too short for some use cases.

Current workaround solution:

Adding to the theme’s functions.php something like this:

add_action( 'http_api_curl', 'my_global_curl_setopt', 1, 3 );
function my_global_curl_setopt( $curl, $url, $options ) {
curl_setopt( $curl, CURLOPT_CONNECTTIMEOUT, 60 ); // Adjust timeout value as needed
curl_setopt( $curl, CURLOPT_TIMEOUT, 60 ); // Adjust timeout value as needed
// Add additional curl_setopt calls here with desired options
return $curl;
}

For a lack of a better word, it feels a bit clunky and repetitive when we are managing over 200 WordPress sites.

Our own use cases:

• 70% of our API use cases are measured in sub-seconds range, ~100ms. These are all pub/sub-driven events, so the response can be very low since complex processing logics are done in the background outside WP altogether.

• 30% of our API use cases do require a real-time response, and these generally still require complex business logics. For example, processing will connect to X number of external APIs. As much as we’re trying to limit these types of processing to a minimum, they are the reality.

My technical perspectives:

• I accept that the increase in the default timeout might exhaust the number of PHP workers on the WP server side and therefore open up possible DDoS attacks.

• As highlighted, I want to reduce what would become boilerplate copy-pasta code that the majority of us will end up doing. This is a cardinal sin, and I feel the community here can debate and help out.

• The majority of open-source HTTP clients, e.g., NodeJS Axios, now understand that the timeout is a difficult problem just like caching itself. So, where can we find the right balance for most real-world cases?
• Just a hypothesis: I have a feeling that if a well-crafted server-side opens the HTTP Output Stream early and simply sleeps for M seconds, then the cURL timeout on the WP side would never occur. The immediate use case here is downloading a very large file on the server side.

This is just a proposal, and I’d like to hear what the community’s sentiments are.

Many thanks,

Hien