typekit / webfontloader

Web Font Loader gives you added control when using linked fonts via @font-face.
Apache License 2.0
9.23k stars 648 forks source link

Consider forcing HTTPS (or adding an option) for Google Fonts #338

Open philipwalton opened 8 years ago

philipwalton commented 8 years ago

I've noticed that when I test on localhost I get http:// versions of Google Fonts. As far as I can tell, it's due to this default configuration: https://github.com/typekit/webfontloader/blob/da5faa9f5262188e33000b33b0b9dfc271b5e97c/src/modules/google/fontapiurlbuilder.js#L18

I'd be great if this could just be hard coded to HTTPS rather than protocol-relative. At minimum, It'd be nice to have the option to always use HTTPS regardless.

monsterlane commented 7 years ago

//link always resolves to your current protocol. If the site you're viewing isn't under SSL it will use http:// if you are it will use https://. If an option was added to force the protocol and it didn't match your current one you'd get a mixed content browser warning.

philipwalton commented 7 years ago

I understand that.

But there are many cases where you're on HTTP and you still want to load the HTTPS version. That doesn't give a mixed content warning, and is actually what folks still on HTTP should be doing.

monsterlane commented 7 years ago

If the main page isn't secured what's the purpose of securing includes? Genuinely curious.

philipwalton commented 7 years ago

We've had reports in the past of users making requests to http://www.google-analytics.com/analytics.js and getting results for a script that wasn't the officialanalytics.jsscript. I could never reproduce this myself, when those users switched to requestinghttps://www.google-analytics.com/analytics.js, they got the correct script. Presumably, since the request wasn't to HTTPS, somewhere in the network pipeline someone was modifying the response. Google has since updated analytics.js to force HTTPS, but other resources still requesting HTTP could experience the same issue.

A second reason is with service worker caching. When testing on localhost (which is technically HTTP even though Service Worker is whitelisted to run on localhost), you end up having to write logic to handle both HTTP and HTTPS, and add both files to the cache (since they're different origins) which is a pain. It's much move convenient to just always request HTTPS.

thomasmattheussen commented 7 years ago

"The protocol relative URL is now an anti-pattern. If the asset is available on HTTPS, always request it with that."

https://www.paulirish.com/2010/the-protocol-relative-url/

ryansully commented 7 years ago

Using HTTPS instead of protocol-relative URL also has considerable performance benefits: https://jeremywagner.me/blog/stop-using-the-protocol-relative-url

jlove73071 commented 3 years ago

Can we please address this. It's straight up silly as Google now redirects the http to https, causing a reload behind the scenes. It's totally pointless to load it using http anymore.