I am interested in switching my entire site from http over to https.
My concern is that I have some content that uses absolute http URLs.
I will need to edit each page in order to change those URLs to relative but that might take me a while to accomplish.
What I would like to know is if there is a way to use Javascript via the Google Tag Manager in order to re-write local absolute URLs to be HTTPS and not HTTP?
If this is possible, could it be used as a permanent solution?
One solution to consider is the Content Security Policy upgrade-insecure-requests
directive.
The upgrade-insecure-requests
directive instructs user agents to
treat all of a site's unsecure URL's (those served over HTTP) as
though they have been replaced with secure URL's (those served over
HTTPS). This directive is intended for web sites with large numbers of
unsecure legacy URL's that need to be rewritten.
It’d amount to configuring your Web server so all pages on your site get served with this header:
Content-Security-Policy: upgrade-insecure-requests
So the effect of adding that header would be: for any page at your site served with an https
URL, any time a browser sees in one of those pages an http
URL for an embedded (sub)resource —whether it be a URL for a stylesheet, script, image, video, or whatever—the browser will automatically (transparently) try to fetch the resource from the corresponding https
URL instead.
For more details, you can see the Upgrade Insecure Requests spec.
2018-05-11 update
The upgrade-insecure-requests
directive is now supported in all major browser engines (including Edge 17+ and Safari 10.3+):
https://caniuse.com/#feat=upgradeinsecurerequests
The downside of using it now is, so far it’s only supported in Firefox (since Firefox 42) and Chrome. But it also:
- has an open Safari/WebKit implementation-tracking/feature bug
- is under consideration by Microsoft for implementation in Edge
P.S., I work at the W3C, where we recently (finally) enabled TLS/https access to all W3C site resources—and since the W3C has hundreds of thousands (maybe millions) of pages with http
URLs for embedded subresources, the way we were able to make it happen was in part by serving the Content-Security-Policy: upgrade-insecure-requests
header across the entire site.
The article Supporting HTTPS and HSTS on w3.org gives more info about the deployment details.
By the time the JavaScript is executed, the problematic resources may already be loading over even loaded.
You can simply search through your code for any instances of http://
and replace those with //
or relative URLs.
If your content is more complex (say, distributed over multiple machines), you can use a mirroring script (like wget --mirror http://example.net/
) to download a static version of your entire page, and search that.
Then, set up HTTPS (first for you only, then for all your testers) and check that everything works fine. Once you are sure that is the case, allow everyone to come over HTTPS. Finally, a bit later, consider redirecting HTTP to HTTPS and implementing secure cookies, HSTS and HPKP.