22

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.

Improve this question
3
  • 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
    – Azeruel
    Commented Jul 22, 2015 at 13:23
  • Yes, I'm seeing this, too, starting yesterday. Driving me crazy, too.
    – Kirby
    Commented Jul 22, 2015 at 17:19
  • 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.
    – bwDraco
    Commented Jul 26, 2015 at 13:21

4 Answers 4

Reset to default
16

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

Improve this answer
6
  • 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
    – TwoDiv
    Commented Jul 22, 2015 at 18:57
  • 1
    It's not specific to your computer. I'm guessing that the other users haven't updated to the latest version of chrome, yet
    – Kirby
    Commented Jul 22, 2015 at 19:07
  • 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!
    – andrewm
    Commented Jul 22, 2015 at 19:17
  • 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
    – TwoDiv
    Commented Jul 22, 2015 at 19:37
  • 3
    @lisburnite you're operating commerce sites that aren't served via HTTPS? You should probably give your customers some protection and fix that...
    – Ashley
    Commented Jul 27, 2015 at 21:22
5

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/

Improve this answer
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']);
}
Improve this answer
2
  • @ any then admin panel wont work.
    – Dhruv Kapatel
    Commented Jul 23, 2015 at 9:05
  • using it on many websites that broke yesterday, without issue
    – Any
    Commented Jul 24, 2015 at 3:19
1

You may try this, to unset the HTTP_HTTPS header.

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .