Make WordPress Core

Opened 8 years ago

Last modified 3 weeks ago

#37454 new defect (bug)

get_avatar_data() delivers different url for scheme=https and is_ssl()

Reported by: neoxx's profile neoxx Owned by:
Milestone: 6.7 Priority: normal
Severity: normal Version: 4.3
Component: Users Keywords: has-patch needs-unit-tests
Focuses: Cc:

Description

get_avatar_data() has an option to set the scheme. If https is used, an image URL is returned which is different to the one which is returned in case delivery is conducted via https without the scheme parameter. I think it would be better to serve the same gravatar url for https pages and explicit https-scheme requests.

Regarding performance and depending on the infrastructure, it could also be benefical to drop https://%d.gravatar.com completely and serve all requests to gravatar independent of the page's protocol via https://secure.gravatar.com/ to benefit from HTTP/2 (http and https://%d.gravatar.com requests are served via HTTP/1.1 whereas https://secure.gravatar.com/ allows multiplexing via HTTP/2).

Attachments (1)

37454.diff (627 bytes) - added by neoxx 8 years ago.

Download all attachments as: .zip

Change History (8)

@neoxx
8 years ago

#1 @neoxx
8 years ago

  • Keywords has-patch added

#2 @SergeyBiryukov
8 years ago

  • Component changed from General to Users
  • Version changed from trunk to 4.3

Introduced in [32845].

#3 @peterwilsoncc
8 years ago

  • Keywords needs-unit-tests added

This will need some unit tests and a decision re: switching all to https. I'm +1 in line with other externally hosted assets.

#4 @neoxx
8 years ago

Following Matt's statement on SSL (cf. https://wordpress.org/news/2016/12/moving-toward-ssl/), we should probably move forward on delivering Gravatars via HTTPS / HTTP/2.

#5 @sippis
7 years ago

This is a quite small change but really important from my point of view. Just noticed that Freedome (privacy VPN from f-secure) blocks requests to gravatar when using http. Haven't tested other privacy products like privacy badger, but I can image that some other tools are also blocking unsecure gravatar.

I think there's really no reason why we shouldn't use always secure.gravatar.com.

This ticket was mentioned in PR #6689 on WordPress/wordpress-develop by @peterwilsoncc.


3 weeks ago
#6

Gravatar.com now redirects HTTP URLs to HTTPS resulting in unnecessary redirects for sites attempting to serve the URLs over HTTP.

This ignores the scheme setting in get_avatar_data() when generating Gravatar URLs to avoid the redirects. The setting is retained to allow for sites using local/external avatar services that do not use HTTPS to serve the images.

I've retained the use of the secure.gravatar.com domain to keep this change focused on the issue at hand but it's worth noting that the Gravatar docs recommend the base domain.

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

#7 @peterwilsoncc
3 weeks ago

  • Milestone changed from Awaiting Review to 6.7

Reviving this as Gravatar now redirects all requests to HTTPS URLs. This can result in unnecessary 301 redirects.

In the linked pull requests:

  • retain the scheme setting for get_avatar_data() to account for other services
  • ignore the scheme setting when generating gravatar URLs
  • updates references in the tests to use secure.gravatar.com

As the WordPress 6.6 beta is fast approaching, I've put this on the 6.7 milestone. I think it would be fine to put in earlier but will allow the release squad to decide if they want to bring it forward.

Note: See TracTickets for help on using tickets.