Standardise api.wordpress.org requests

[dd32]

While looking at requests to api.wordpress.org a few things stood out

• Browse Happy, Credits, and Importer API requests only happen via HTTP and not via HTTPS
• Events API requests only occur over HTTPS, even if WordPress doesn't support SSL. Users on not-so-good hosting such as this are a good target to support at events.
• The WordPress version sent is not always a valid version, due to $wp_version not being used - this makes it harder to return consistent responses based on the WordPress version
• The User-Agent differs between requests slightly, which prevents cross-matching api requests from the same site to multiple endpoints (Which makes it hard to determine why requests are still occurring over HTTP instead of HTTPS)

[dd32]

In 41605:

Standardise on performing api.WordPress.org requests over SSL when possible, falling back to non-SSL when appropriate.
This also standardises the User-Agent used when communicating with WordPress.org, allowing for more consistent version detection.

Fixes #42004.

[dd32]

Just to note:

The unreachable & retry-over-HTTP code from the core/plugins/themes update checks were not copied over to Browse Happy, Importers, Events, or Credits API calls. In these areas it's not as critical if the requests fail gracefully (Importers has a hard-coded list as a backup). While Events could benefit from it, it's unlikely to be a significant group of users for whom SSL requests are failing currently (where WordPress thinks it'll work, but doesn't).

The User-Agent standardised on is what is used for the Core version check, everything else was similar but slightly different, trailing slashing differences and possibly scheme differences based on different filters applying to the URL.
I only changed the User-Agent sent to api.wordpress.org, as we specifically override it in this case. The User-Agent used for general HTTP requests is not a trailing-slashed URL, while we send a trailing-slashed URL to api.wordpress.org.

[johnbillion]

1. Should this be backported to older branches?
2. Should network_home_url() be used in the user agent instead of home_url() to improve consistency of calls coming from a Multisite installation?

[dd32]

Replying to johnbillion:

1. Should this be backported to older branches?

The SSL stuff could be backported, as it's a hardening/consistency change rather than a security focus I wasn't planning to. It may make sense to backport it in the future if we make any future security changes which relate to it.

2. Should network_home_url() be used in the user agent instead of home_url() to improve consistency of calls coming from a Multisite installation?

Quite possibly, however the Core/Plugin/Theme checks are only run on the main site of a network, and all the other calls are mostly irrelevant to server-side stats as they're so sporadic and on-demand.
I don't see any urgent need to make those requests super consistent, just as long as they're consistently requesting over SSL with a valid version number - the URL in that case mostly allows for simpler differentiation between any two requests, so it doesn't really matter what it is, just as long as it's consistent for any given request type.

If all these calls went through a central wrapper which dealt with HTTP fallback & user-agent setting/etc I'd agree that network_home_url() would be a better choice here, given the number of locations in Core we do api.wordpress.org requests (It surprised me honestly) that would probably be a wise enhancement for future maintainability.