The feature makes it easier for existing sites to transition to HTTPS.
One of the main obstacles in an HTTPS transition is removing any and all mixed content issues. In order for a browser to display the green padlock, which indicates you have a secure connection, every single resource on the page needs to be loaded over HTTPS. This means every image, every script, every object. If just a single resource, even one out of hundreds, is fetched insecurely over HTTP, you have a mixed content issue and will not see a green padlock.
Mixed content issues can vary page to page, so fixing them is quite a headache. Some developers take the time to painstakingly comb through their sites, updating resources from HTTP to HTTPS. Others automatically rewrite every instance, hoping that it does not cause any errors. But there is a better solution.
Upgrade-insecure-requests is an HTTP header specifically designed to fix this problem. When a browser (or other client) encounters this header, it tells them that they should automatically fetch all the resources on that site securely over HTTPS.
One of the key features of Upgrade-insecure-requests is that it does not require changing the source code of individual pages, making it very easy to implement. This can help a site eliminate their mixed content issues with a single change.
Browsers defer to what a website explicitly tells them to do. Because HTTP was widely used until very recently, many sites explicitly included “http://” in their source code, so browsers continue to load content insecurely even if the site uses HTTPS. The more legacy content a site has, the more valuable this feature can be for them because legacy content often contains hardcoded HTTP URLs.
Mike West, an engineer at Google, designed upgrade-insecure-requests. He wanted to make HTTPS migrations easier. West wrote “we should remove this burden from site authors by allowing them to assert to a user agent that they intend a site to load only secure resources.”
However, Upgrade-insecure-requests only works if a user’s browser supports the feature. Therefore, it’s only a useful tool if it’s widely deployed in client side software. Otherwise a significant number of people will continue to experience insecure mixed content connections.
For the most part, most major browsers support Upgrade-insecure-requests, including Firefox and Chrome. Overall, 60% of global users support Upgrade-insecure-requests.
There are a few household-name browsers that do not yet support it, the most popular among those being Safari and iOS browsers. That’s because, until recently, Upgrade-insecure-requests was not supported by Webkit, the browser engine that powers those browsers.
CanIUse.com, a website that tracks support for web technologies across popular web browsers, estimates that 8.16% of global traffic comes from iOS. It’s significantly more popular in the US, where iOS accounts for 18.96% of the browser market. Safari for Mac OS contributes a few more percentage points on top of that (1.6% globally, and 3.77% in the USA).
Now, it’s finally going to reach consumers’ devices. When iOS 10 releases tomorrow, on the 13th, everyone who upgrades will receive a new version of Webkit that will give the power of Upgrade-insecure-requests to every browser.
Safari 10, shipping with Mac OS 10.12 Sierra, will also include support for upgrade-insecure-requests which will release on September 20th.
Microsoft’s browsers, Edge and Internet Explorer, do not have support for upgrade-insecure-requests. It is very unlikely that Internet Explorer will receive support. Edge’s developer website says support is “under consideration,” which means it will hopefully receive support but that may not be anytime soon.
Zack Tollman, Wired.com’s application architect, broke this news last week. He confirmed to us that the iOS 10 beta does indeed support Upgrade-insecure-requests.
 More specifically, it’s a Content Security Policy directive