`wp_http_supports()` doesn't reflect what Requests can do

[dd32]

While reviewing what parts of WP_HTTP can be removed in #37705, I noticed that wp_http_supports() still performs it's checks against the WP_HTTP transports rather than querying against Requests to see if the request can be performed or not.

The only capability which we supported was ssl.

Three options:

1. Query SSL ability against Requests (if it supports that)
2. Deprecate and always return true;
3. Implement a small check to see if SSL requests will be able to proceed, checking for cURL features or openssl being available (and all the other streams requirements being satisfied).

The above options are in my order of preferences, we should support it if possible, but I'm not afraid of just no-oping the function.

Marking for 4.7, with the potential for 4.6.x backporting.

[jorbin]

I like the first option, though a quick look through Requests makes me think it doesn't have that functionality. @rmccue - Does that sound correct?

[dd32]

I couldn't see anything in Requests that we could use, but I also feel that adding a method for checking to see if we can *maybe* support SSL wouldn't be out of the question..

[desrosj]

@rmccue do you have any suggestions here?

[dd32]

Opened ​https://github.com/rmccue/Requests/issues/250 upstream.

[dd32]

Punting, it was broken in 4.6, mostly works still as long as the majority of the WP_HTTP logic remains in sync with Requests (which it is at present).

[desrosj]

I’m going to close this out as reported upstream. When Requests is updated and the PR above is merged, this will make its way in.

[jrf]

Requests 2.0.0 has been released and includes the change needed to address this.

The update to Requests 2.0.0 is expected to still go into WP 5.9. Once the upgrade patch has been merged, we should be able to address this ticket with relative ease.

Related: #54504

[peterwilsoncc]

Per discussion in a recent bug scrub, I am moving this off the 6.0 milestone as it depends on Requests 2.0.0 being merged.

Props @costdev, @chaion07.

This ceases using the Deprecated WP_HTTP::_get_first_available_transport() method and calls Requests directly.

Trac ticket: https://core.trac.wordpress.org/ticket/37708

[dd32]

8 years later, this is causing some issues with WordPress playground, which uses a custom fetch transport.

​https://github.com/WordPress/wordpress-playground/issues/1494

After doing some digging with the aid of wpdirectory.net I've been unable to find any instances of wp_http_supports() usage which looking for a capability other than ssl, which is good, because we (WP_HTTP & Requests) don't support anything else here :)

The only instance I could find that was not looking for SSL was code similar to this:

if ( wp_http_supports( array(), 'http://www.example.com/' ) ) { ... }

The attached PR implements option 1 from the ticket, using the Requests v2 method.

[peterwilsoncc]

Moving this on to the 6.7 milestone for consideration.

I've approved the ​linked pull request. @jrf, if you have bandwidth it would be great if you could take a quick look at it too.

[peterwilsoncc]

In 58934:

HTTP API: Update wp_http_supports() to use Requests.

Update the capabilities check in wp_http_supports to use WpOrg\Requests\Requests::has_capabilities rather than the deprecated WP_HTTP::_get_first_available_transport().

Props dd32, mukesh27, costdev, desrosj, johnbillion, jorbin, jrf, chaion07.
Fixes #37708.

Merged r58934 / ​https://github.com/WordPress/wordpress-develop/commit/24e87757cd068b29df98c9f6ae464baaf4659670