Chrome adds weird HTTPS:1 header to all requests

Question

I've been getting a lot of weird errors on websites that relate to HTTPS. These sites works great in FF and IE, but fail to load in Chrome. It appears that though I'm requesting an unsecured URL (http), Google Chrome adds an extra header HTTPS:1 to the request.

This causes some servers, probably some that use offload SSL and provide a shared hosting, to respond with an error since there is no SSL on the server.

I'm not being redirected to a secured page (HTTPS), rather all internal URLs in the source are being edited to https.

I've checked the connection with fiddler. This parsing is not being made on my computer and the only difference is this HTTPS:1 header.

I've created a simple PHP page that prints the $_SERVER variable. When I access it with chrome I can see: [HTTP_HTTPS] => 1. I cannot see it with FireFox.

I've tried clearing all data, unpairing chrome from my google account, and removing and installing Chrome from scratch.

Anyone have any idea about this? It is driving me crazy.

Solution 1

Apparently a bug in version 44, seems to be fixed in the latest update. I'm now using 44.0.2403.107 and the problem seems to gone away.

More information here: http://www.zdnet.com/article/brand-new-chrome-44-release-added-a-bug/

Solution 2

Most likely those sites that you are having problems with are running server code that incorrectly interprets the HTTPS: 1 request header. For example the Wordpress WooCommerce plugin, which is running on about 900,000 sites, has buggy code that incorrectly handles the HTTPS: 1 header. See their latest patch document here: https://woocommerce.wordpress.com/2015/07/07/woocommerce-2-3-13-security-and-maintenance-release/

There is a similar post on StackOverflow: https://stackoverflow.com/questions/31565155/wordpress-woocommerce-forces-https-when-it-shouldnt/31570584#31570584

To give more detail: Chrome has implemented the Upgrade Insecure Requests specification from the World Wide Web Consortium (W3C). Section 3.2.1 of that specification is The Upgrade-Insecure-Requests HTTP Request Header Field which states

3.2.1. The Upgrade-Insecure-Requests HTTP Request Header Field

The Upgrade-Insecure-Requests HTTP request header field sends a signal to the server expressing the client’s preference for an encrypted and authenticated response, and that it can successfully handle the upgrade-insecure-requests directive in order to make that preference as seamless as possible to provide.

This preference is represented by the following ANBF:

"Upgrade-Insecure-Requests:" *WSP "1" *WSP

Sites like those running the WooCommerce plugin in Wordpress are incorrectly rewriting all the URLs in the response as https:\\ links if the HTTPS: 1 header was set in a non-secure (http) request.

As an end user of that site, the only easy work around is to use a browser other than Chrome until those web sites are repaired

Solution 3

its more than just wocommerce, its all of wordpress that is going haywire causing bad css, images and etc.

add this to near the top of your wp-config.php to remove it

if($_SERVER['HTTP_HTTPS'] && !$_SERVER['HTTPS'])
{    unset($_SERVER['HTTP_HTTPS']);
}

Solution 4

You may try this, to unset the HTTP_HTTPS header.

if(!isset($_SERVER['HTTPS']) || $_SERVER['HTTPS'] != 'on') {
    unset($_SERVER['HTTP_HTTPS']);
}

View more solutions

Comments

[Admin]

I had the same issue on chrome canary, but only on a specific site where I fooled around with http->https redirections. I guess it has something to do with the 301 redirect cache. Chrome did not redirect me to https after a complete browser cache clear. However it does not solve the https header problem. I "solved" it by not using canary for the specific site any more. Today the same issue began again on chrome stable BUT NOT on canary anymore. I guess the cache on canary is expired. I've not tested it for some time. Looks totally random for me. Sorry for not giving you an answer. But, since I

[Admin]

Yes, I'm seeing this, too, starting yesterday. Driving me crazy, too.

[Admin]

Chrome is very, very aggressive when it comes to security. Google is probably doing this for business reasons: if it can't secure user data against government actors, users will lose their faith in Google very quickly. Hence, Google considers establishing itself as a leader in Internet privacy a top priority, despite the fact that its ad-based business model utterly relies on user behavioral tracking. Users trust Google to be a safe steward of their personal data, to not leak data out to unauthorized third parties, so they can't afford to do anything less.

[TwoDiv]

Thanks for the elaborated reply, I've seen that this code was implemented, but since this issue is specific to my computer (I've checked with different computers in the office) I assume that there is a way to turn that off. Other computers does not send the HTTPS:1 header, it is specific to my computer

[lisburnite]

wow this going to be a potentially big problem for WooCommerce. I run two separate (non https enabled) sites on Woo and have just patched them with the fix they've released however I can imagine a lot of shop owners complaining about this one!

[TwoDiv]

I think that it's not only WooCommerce issue, rather they way the Server reads the headers. On my work, we use Off-load SSL, and we use the HTTP-Proto parameter to let the server know if the request arrived in HTTPS. The server gets a simple HTTP request and parse it as though it was HTTPS. I assume that this is the same issue and if the server configuration does not allow HTTPS, doesn't have SSL, or use different folders for http and https - they will crash

[Dhruv Kapatel]

@ any then admin panel wont work.

[Any]

using it on many websites that broke yesterday, without issue

[Ashley]

@lisburnite you're operating commerce sites that aren't served via HTTPS? You should probably give your customers some protection and fix that...

[lisburnite]

@AshleySteel I plan to, they're both relatively new sites and the priority was to get them live first. Just waiting on both clients purchasing SSL certs and I'll get them in place.