Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#42004 closed defect (bug) (fixed)

Standardise requests

Reported by: dd32's profile dd32 Owned by: dd32's profile dd32
Milestone: 4.9 Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords:
Focuses: Cc:


While looking at requests to 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)

Change History (4)

#1 @dd32
7 years ago

  • Owner set to dd32
  • Resolution set to fixed
  • Status changed from new to closed

In 41605:

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

Fixes #42004.

#2 @dd32
7 years ago

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, 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

#3 follow-up: @johnbillion
7 years ago

  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?

#4 in reply to: ↑ 3 @dd32
7 years ago

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.

  1. 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 requests (It surprised me honestly) that would probably be a wise enhancement for future maintainability.

Note: See TracTickets for help on using tickets.