Remember that HTTP vs HTTPS adds yet another dimension you have to take into account. This bit me the other day. I run a site at example.com (I prefer a naked

Remember that HTTP vs HTTPS adds yet another dimension you have to take into account. This bit me the other day. I run a site at example.com (I prefer a naked domain, for no technical reasons whatsoever), with a CNAME record for the www subdomain. But I only want to serve the site over HTTPS. So http://example.com http://example.com redirects to https://example.com https://example.com, as does http://www.example.com http://www.example.com. Simple enough, right? I however started receiving some spurious reports that the Google Account login option wasn't working on the site, which was quite puzzling at first. Turns out, some users were manually entering https://www.example.com https://www.example.com as the address (it's not indexed or linked to anywhere in this form that I could find), which was being handled by the Nginx default_server directive on port 443, causing the site itself to appear to work just fine at https://www.example.com https://www.example.com as well. But the Google OAuth service checks the authorized origins for any client side requests, saw www.example.com and was expecting example.com so simply failed silently. Doh! TLDR summary: If you redirect to HTTPS by default, check that all 4 options ([www, naked] * [http, https]) work correctly, and that all redirect just ONE canonical name to keep things sane. And make sure the 3 redirects preserve any request URI parts after the domain as well.