New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 42 users

Issue metadata

Status: Duplicate
Merged: issue 501842
Buried. Ping if important.
Closed: Jul 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: ----

Sign in to add a comment

Issue 505268: Forcing Wordpress sites to use https even when not directed

Reported by, Jun 28 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36

Steps to reproduce the problem:
1. Attempt to log into any self-hosted wordpress site

What is the expected behavior?
Should be redirected to the standard http dashboard url unless an SSL is installed and otherwise directed to use the installed SSL via a plugin or htaccess.

What went wrong?
Users are force redirected to httpS instead of http, regardless of htaccess or plugin directives. Even on sites that have never used https.

Did this work before? Yes Stable version 43.

Chrome version: 44.0.2403.61  Channel: beta
OS Version: OS X 10.10.4
Flash Version: Shockwave Flash 18.0 r0

Clearing cache/history, incognito mode, clearing from HSTS-- none fix the problem. The only fix I've found is to roll back to v43.

Comment 1 by, Jun 28 2015

Labels: -Restrict-View-SecurityTeam -Type-Bug-Security -OS-Mac Cr-Internals-Network-SSL OS-All
Status: Assigned
This is not a security bug, although it may be a general bug. I'm assigning to davidben for further investigation.

Comment 2 by, Jun 29 2015

Labels: Needs-Feedback
Owner: ----
Status: Available
Retriaging to available.

Can you please provide a chrome://net-internals log, as per ? This will help detail why you're being redirected.

Comment 3 by, Jun 29 2015

If there's a particular URL you could provide that I could take a look at, I'd like to check if this is the `HTTPS` header we've started sending in 43.

Comment 4 by Deleted ...@, Jun 29 2015

There is another behavior that might be related to this https forced redirection.
Take a look at this site:
When I access it with 44.0.2403.61 beta there are stylesheets and scripts that are converted to https protocol, so it basically it ends up being displayed without styles.

Comment 5 by, Jun 29 2015

re: #4 above - yes, that is also a symptom.

Comment 6 by, Jun 29 2015

re: #3) I don't really want to publicly post the login pages for live sites, can I email one?

Comment 7 by, Jun 29 2015

Certainly sounds like my fault, then. Assigning to myself.

Do you see the same behavior in Canary or Dev channel (45)? Or just in Beta (44)?

sarah@: I'll poke at the butterfly link cata.rock provided. If I can't reproduce it there, I'll ask you for some more detail.

Comment 8 by, Jun 29 2015

Labels: -Cr-Internals-Network-SSL -Needs-Feedback
Mike: Removing the Cr-Internals-Network-SSL layer - sounds like this should be triaged through blink.

If you do think it's something SSL-y, please make sure yourself (or reporters) adds net-internals. ta :)

Comment 9 by, Jun 29 2015


Comment 10 Deleted

Comment 11 by, Jun 29 2015

Modified (removed site url) net-internals attached.
1.3 MB Download

Comment 12 Deleted

Comment 13 by, Jun 30 2015

Chrome beta send a new header : HTTPS:1
it breaks woocommerce check for https, so a connection to the http version will try to load assets with https (and possibly breaks the website is https is not supposed to be supported).
$_SERVER['HTTP_HTTPS'] is set to 1 due to the header.

Comment 14 by, Jul 2 2015

I'm having the same issue, is there something that I could do to help? Like a log file or something?

It happens inside Chrome 45.0.2438.3 dev-m (64-bit) and also Canary 45.0.2445.0 canary (64-bit)

Inside a Virtual Machine using Windows 7 and Chrome this is not happening.

Comment 15 by, Jul 2 2015 I would assume this report is related to  issue #495991  ( As you seemed to have alluded to. For what it is worth, the implementation of `Upgrade Insecure Requests` looks to be done per specifications and the software listed as being affected simply responds incorrectly to the HTTPS header: . So the onus seems to be more on the responding servers or software to carry their end of the bargain if the draft protocol is going to be used on the client-side.

If it is helpful, attached is the behavior in a net-internals log.
809 KB Download

Comment 16 by, Jul 7 2015

We are having the same issue with a wordpress site. It happens with chrome 44.0.2403.61 [beta m] win 7. First you only see the navigation tree (pure without css and everything)and if you click a link you will get error messages that the connection ist not save and that the server certificate doesnt correspond with the url.

Comment 17 Deleted

Comment 18 by Deleted ...@, Jul 7 2015

I'm using Chrome Version 44.0.2403.61 beta (64-bit) on Mac and I can confirm this is a really annoying bug!

I own a self hosted website powered by nginx and when I try to access it I'm redirected to https, I don't even have a SSL certificate installed on the server and my website is throwing impossible errors on the developer's panel.  I've been experiencing this issue with a lot of wordpress websites and blogs I usually read.

I first started digging on nginx as I thought it was a sever-side malfunction until I searched for this issue and landed here. 

I hope it get solved soon. Unfortunately I'll have to stop using my favorite browser until this issue is solved on a next update. Chrome 32 bit is out of question, I just can't use it anymore, performance is incredible poor.

Comment 19 by, Jul 9 2015

Same here on chromeos beta channel.

If i view the web page source it's changed and every http link (for css, js and so on) is rewritten as https and usually not found.

Comment 20 by Deleted ...@, Jul 14 2015

It looks like it's fixed in 44.0.2403.81.

Comment 21 by, Jul 14 2015

re: #20 You have any indication this was actually removed (e.g., another issue, pull request)? I am still seeing this `HTTPS: 1` header set in Version 46.0.2455.0 canary (64-bit).

Comment 22 by, Jul 14 2015

Problem not fixed yet, Chrome 45.0.2454.6 dev-m (64-bit).

Comment 23 by, Jul 15 2015

Mergedinto: 501842
Status: Duplicate
Duping this against  issue 501842 ; I've landed a fix, and I'll try to get it merged back on that bug.

Comment 24 by, Jul 22 2015

Having same issue after updating the chrome to Version 44.0.2403.89 beta-m (64-bit).

I thought it is something wrong with our website, glad to know its chrome known issue, how to be solved soon. Cannot use chrome due to this bug.

Comment 25 by, Jul 22 2015

The fix didn't make it into the initial release of 44. It did make it into the branch for the first stable update, so the next time we roll Chrome, this will be taken care of.

Comment 26 by, Jul 22 2015

The problem was in beta 44, now it's in PUBLIC 44, which means a HUGE swath of wordpress sites are throwing invalid "Not private" errors, and how long will it be before the next stable refresh is out, another week? There's no way you can push a fix for this any faster? I would consider it a huge problem for a vast number of users.

Comment 27 by, Jul 22 2015

All our WordPress websites are broken and totally useless. This bug is breaking far too many WordPress sites out there!

Comment 28 by, Jul 22 2015

The google chrome update plus the eventon-plugin = crash. A lot of sites are affected!

Comment 29 by, Jul 22 2015

Hi everyone,

Just wrote a tiny WordPress Plugin to turn off HTTPS. It is not perfect but might help until waiting for the next Chrome release. 


Comment 30 by Deleted ...@, Jul 23 2015

Really upset that this bug hasn't been fixed in stable version. This is really, really bad!

Comment 31 by Deleted ...@, Jul 23 2015

Could we please get time estimate for when this will be fixed?

Comment 32 Deleted

Comment 33 by Deleted ...@, Jul 23 2015

This is now about 40 of my Wordpress Sites. links to external files are now showing https even though we never use https. Can't believe this passed BETA
Any chance on an update to this issue?
I have a number of affected sites

and loads more, going to try the temporary fix listed here, but would really like some feedback on why this is happening.

Comment 36 Deleted

Comment 37 by, Jul 23 2015

Copy/pasting from  issue 501842 , which this bug duplicates:

I apologize for the breakage; I apparently underestimated the impact based on the feedback during dev and beta:

1. A fix has been merged back to the stable branch (, but not quickly enough for the stable release that went out on Tuesday. I'll raise this bug with our release managers to see what can be done with regard to updating the stable channel.

2. Going forward, Chrome will no longer send `HTTPS` headers (We renamed the header from `HTTPS` to `Upgrade-Insecure-Requests` in response to the reports we got during beta), so ,at least with regard to Chrome, something like #38's suggestion is a reasonable short-term workaround. I'd certainly recommend removing it once Chrome pushes an update, but it will mitigate the issue for the moment.

Comment 38 by, Jul 23 2015

You can mitigate the issue server-side by asking your http server to remove the HTTPS header. For instance, with apache, you can add, in a .htaccess file:
RequestHeader unset HTTPS

Comment 39 by Deleted ...@, Jul 23 2015

And if your site uses a mix of SSL and non-SSL pages as does ours, the possible work-arounds don't work!

I am also getting "This webpage has a redirect loop" ERR_TOO_MANY_REDIRECTS. This is going to cost many people to loose money. PLease see if the fix can get pushed out now.

Comment 40 by, Jul 23 2015

So far I've only seen WordPress websites running WooCommerce having this issue, when they are running an old version before 2.3.12 in which WooCommerce removed a bad fix. See also
Are there any other situations known?

Comment 41 Deleted

Comment 42 by, Jul 23 2015

> So it goes beyond WordPress.

Right, I came here to say the same thing. This looks like an Apache + PHP bug.

Comment 43 by, Jul 23 2015

Unfortunately the error is not a WooCommerce thing only. There are other plugins ( e.g.: Contact Form 7 ) and themes which use the is_ssl() function. Using this function causes all links to become HTTPS.

In case you do not want to mess with a code or .htaccess as a quickfix you can use this small plugin which basically disables HTTPS and does nothing else. Here is the code on GitHub

It should be used for a short amount of time until the Chrome Update is out. Cheers

Comment 44 by, Jul 23 2015

I'm using Contact Form 7 on various websites and haven't seen any issues yet. Can you tell me how to reproduce that?

Comment 45 by, Jul 23 2015

I was referring to a comment by this user:

In our case the error occurs even without any plugin. The them I use, uses the is_ssl() function and based on that loads some file either via HTTP or HTTPS. the function always returns true.

Comment 46 Deleted

Comment 47 Deleted

Comment 48 by Deleted ...@, Jul 23 2015

re: #47 - this is just the plugin in #43 wrapped up to include a donation form in the WP admin, which is pretty disgusting.

Comment 49 by, Jul 23 2015

I've got this issue on Chrome stable 44.0.2403.89-1 on Ubuntu Linux. It's made a WordPress blog I inherited on cPanel completely unusable. The blog does use WooCommerce.

Comment 50 by, Jul 23 2015

It's a WooCommerce issue, they were doing bad things with $_SERVER['HTTP_HTTPS'] - Update WooCommerce to >= 2.3.

Comment 51 by, Jul 23 2015

I to am having this issue, but only on one of my sites.  I am using Chrome 44.0.2403.89 (64-bit) on a Mac.  I only updated Chrome today and it started happening straight away.

Hopefully there will be a fix soon.

Comment 52 by Deleted ...@, Jul 23 2015

Keep in mind, even after chrome fixes this problem there will still be people having issues because they might not update right away.

So keeping "RequestHeader unset HTTPS" in your .htaccess would be a good idea for a few weeks after they fix the bug.

Comment 53 by, Jul 24 2015

Ive been having issues the past 3 days, started with CSS not being loaded, then redirect loops, now im getting HTTPS/Security issues as well on WP/Woocommerce sites. Im going to use google chrome canary until this is fixed.

Comment 54 by, Jul 24 2015

There is a Woocommerce update that works around this Chrome bug.

Comment 55 by, Jul 24 2015

Thanks, I guess that's ok in the meantime but there are so many sites running WP/woo its pretty frustrating. I just switched to Canary and that seems to work.

Comment 56 by Deleted ...@, Jul 24 2015

The woo commerce update allows the problem to be worked around so that the website looks/works fine in Chrome.

Comment 57 by Deleted ...@, Jul 24 2015

Does the woocommerce workaround work if portions of your site require SSL?

Comment 58 by Deleted ...@, Jul 24 2015

I would like to thank everyone who has been posting in this thread. 
Especially Username: for posting the htaccess solution.
This saved me since my site does not use SSL at all..

Am using wordpress 4.2.3. and woocommerce 2.3.8. Running chrome 44.0.2403.89 m.

Just convinced my client to switch from IE to chrome, hope i wont need to advice otherwise............ please keep us updated.

Comment 59 by, Jul 24 2015

Thanks for the htaccess solution, adding RequestHeader unset HTTPS did the trick for me. Just ot confirm, SSL still works for checkout pages in WooCommerce with this fix.

Comment 60 by, Jul 24 2015

The real solution is to update WooCommerce, not to hack your .htaccess file or install plugins.

Comment 61 by Deleted ...@, Jul 24 2015

Guys this is bug with WordPress Woo-Commerce old releases before 2.3. Once you update the Woo-Commerce to 2.3 you can see this issue is fixed.
Kindly reply if this is helpful.


Comment 62 by Deleted ...@, Jul 24 2015

Also dont forget to clear the browsing cache
Also this bug is with chrome 44.x.x.x only version 39.x.x.x is working perfectly.

Comment 63 by Deleted ...@, Jul 24 2015

Guys this is bug with WordPress Woo-Commerce old releases before 2.3. Once you update the Woo-Commerce to 2.3 you can see this issue is fixed.
Also dont forget to clear the browsing cache
Also this bug is with chrome 44.x.x.x only version 39.x.x.x is working perfectly.

Kindly reply if this is helpful.

Comment 64 by Deleted ...@, Jul 24 2015

To be more precise, WooCommerce 2.3.12 fixes this issue

2.3.12 - 06/07/2015
Fix - Fixed Google Chrome forcing to use SSL. This can cause some issues on websites behind load balancers or reverse proxies. Read more.

Comment 65 by Deleted ...@, Jul 24 2015

When will this fix be released?

Comment 66 by, Jul 24 2015

So far my experience is that none of these 'hacks' and workarounds are working. I still get the SSL errors in WordPress after the upgrade to Chrome v44. Please fix this!

Comment 67 by Deleted ...@, Jul 24 2015

Right now the fix that finally worked for us (our site uses a mix of http/https) is to comment out the below lines in woocommerce.php:

if ( ! isset( $_SERVER['HTTPS'] ) && ! empty( $_SERVER['HTTP_HTTPS'] ) )

Comment 68 by, Jul 24 2015

Guys for now use Canary, go in and update your WP and Woo.

Comment 69 Deleted

Comment 70 by, Jul 24 2015

Pages do not work correctly on the https protocol.
167 KB View Download
195 KB View Download

Comment 71 by, Jul 25 2015

As noted in, the fix is now live on M44 Desktop stable channel version 44.0.2403.107 (Win, Mac, Linux).

Comment 72 by Deleted ...@, Jul 25 2015

I can confirm that updating woocommerce has fixed this issue.

Comment 73 by Deleted ...@, Jul 25 2015

Yes but in several sites Im not the admin and the issue continues.

Comment 74 by, Jul 27 2015

I just updated Chrome to Version 44.0.2403.89 and I am still getting the HTTPS privacy error when going to the WP Dashboard! I have found though that this fixes it, but I shouldn't have to enter hacks into my files - please fix this!

/* add this to your functions.php file in WP to bypass SSL error */
function https_chrome44fix() {
  $_SERVER['HTTPS'] = false;
add_action('init', 'https_chrome44fix',0);

Comment 75 by, Jul 28 2015

I think this goes back to this spec here:

So, if anything, either the W3C spec *or* PHP is broken and website owners will likely experience the same breakage again when other browser vendors start to implement that spec...

Comment 76 by Deleted ...@, Jul 29 2015

I too am having this issue, very annoying!!! more reasons to abandon chrome :(

Comment 77 Deleted

Comment 78 Deleted

Comment 79 by Deleted ...@, Sep 4 2015

Hey, at least Google's focusing on the IMPORTANT things, like their new logo.

Comment 80 by Deleted ...@, Sep 5 2015

No one investigated and they make relese with this bug. 

What a bucnh of noobs omg.  i can't believe this happen.

Comment 81 by Deleted ...@, Oct 3 2015

menu chrome, try in advance setting,  click reset setting... hope this help... mantapps

Sign in to add a comment