Opened 7 years ago
Last modified 6 years ago
#37454 new defect (bug)
get_avatar_data() delivers different url for scheme=https and is_ssl()
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Awaiting Review | 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)
Change History (6)
#3
@
7 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
@
6 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
@
6 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.
Introduced in [32845].