Network access error stream_socket_client() ssl://... Host is unreachable

[tellyworth]

Some network access fails with a ssl stream error when running with kitchen-sink extensions and networking enabled.

For example, on the Dashboard page, the Events widget shows this error:

RSS Error: WP HTTP Error: stream_socket_client(): Unable to connect to ssl://wordpress.org:443 (Host is unreachable)

The browser never actually attempts to make this particular request; something is going wrong either in PHP or the WP HTTP code.

Steps to reproduce:

1. Visit https://playground.wordpress.net/?networking=yes&php-extension-bundle=kitchen-sink&url=/wp-admin/
2. Check the Events widget on the Dashboard page; you'll see a HTTP error similar to above.
3. Check the Browser console and network tab; you'll see that no request was made to a wordpress.org RSS feed.

Expected: either the request should succeed, or the limitation should be documented if this is intended behaviour.

[dd32]

After looking into this, from what I can tell, the http_api_transports filter doesn't appear to be in use anymore when using the normal wp_remote_* functions. I suspect it probably is if you call WP_HTTP_Curl::request() directly.

To me, it appears that it's no longer possible to disable the curl/streams handlers in Requests, I actually suspect it might not have been possible to disable them previously either; but because the curl and streams extensions weren't loaded, it was falling through to the Fetch handler.

I'm not seeing a filter in Requests to specify the transport to use either:
https://github.com/WordPress/wordpress-develop/blob/8448d06c49ade781ff6971054d79a84d90dc54ff/src/wp-includes/Requests/src/Requests.php#L225-L259

I suspect, the way forward is to get a filter into the Requests class; or have playground overwrite/modify the add_transport() function to allow us to load the Fetch handler ahead of others:
https://github.com/WordPress/wordpress-develop/blob/8448d06c49ade781ff6971054d79a84d90dc54ff/src/wp-includes/Requests/src/Requests.php#L205-L216

Example:
https://playground.wordpress.net/?php=8.0&networking=yes&plugin=debug-bar-console&plugin=debug-bar&wp=6.4&storage=none&php-extension-bundle=kitchen-sink&networking=yes

[dd32]

I think I found a workaround.. there is a generic filter that let's us change some of the basic Requests args, and it includes an option we can use to force a specific transport to be used:

add_action( 'requests-requests.before_request', function( $url, $headers, $data, $type, &$options ) {
	$options['transport'] = 'Wp_Http_Fetch';
}, 10, 5 );

Here's a request with, and without the above filter:

[adamziel]

Note I've merged a reflections-based fix around the same time this issue was reported, but I think @dd32's PR is a more elegant solution and I'd love to move forward with that one instead.