Brand new ​Chrome 44 release added a bug

The latest release of Chrome introduced a bug that causes some sites without SSL support to misbehave.

The good news is that Chrome 44 fixed numerous bugs. The bad news is it also introduced a bug that causes some sites to fail to render properly while others fail completely with a ERR_TOO_MANY_REDIRECTS error message.

Google's development team is well aware of the problem and is working on getting the fix into the Chrome stable channel for an immediate update.

This bug started from the best of intentions. The code was meant to encourage the use of HTTPS for a more secure Web experience. Unfortunately, instead of encouraging the use of a secure link, if one was available, it forced the web browser to redirect to HTTPS pages... even if there were none available, This happened regardless of the web-server's htaccess settings or plugin directives even on sites that have never used https.

Whoops.

For the most part, this problem is being seen in self-hosted Wordpress sites. It's not limited to those. Other sites that don't support HTTPS or use a mix of HTTP and HTTPS pages are also being affected.

As one bug reporter put it, "This bug [is] critical, you need to push a fix ASAP. 'Soonish' is not going to cut it."

He continued, " The Internet is starting to react to this bug. Users are starting to adopt 3rd party plugins and patches to fix the issue from their end, this could lead to even more trouble down the road. It should never have made it into a stable release in the first place, as it is obvious the amount of breakage it causes."

One such fix is for web administrators to put "RequestHeader unset HTTPS."

in your site's .htaccess file.

This is a kludge and I can't recommend it unless your site gets a lot of traffic from Chrome users and it's been totally knocked out of action. The reasons I don't care for it is that it may disable HTTPS if you add Secure-Socket Layer (SSL) security in the future and Google is expected to patch Chrome later today.

Mike West, a Chrome developer, replied, "I apologize for the breakage; I apparently underestimated the impact based on the feedback during dev and beta." Therefore the following steps are being taken.

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.

As annoying as this has been, it appears however that may not be a Chrome problem per se. Instead it may be that Chrome has simply uncovered a common serious web server bug that might be used in the future for attacks.

Danish developer and system administrator, Tom Sommer, wrote:

At its core, it's an Apache/PHP issue.

If the client sends the "HTTPS: 1" request-header, it triggers something in Apache/PHP so it incorrectly sets the HTTPS=1 and SERVER_PORT=443 server-variables. Any application (including WordPress' is_ssl() function) that depends on these server variables will break if the server does not support SSL.

It's a potential security issue, because in reality you can trick an application into thinking it's running SSL, when in fact it is not. I'm not entirely certain if it's an Apache or PHP bug, but someone should investigate/report. If the problem exist in IIS; then it's obviously a PHP bug.So, it's not really Chrome's fault, but Chrome triggers this bug by sending the HTTPS: 1 header.

That certainly bears further investigation. For now, if you run into a site that's not working properly with Chrome, try it with another web browser. The problem may well be with Chrome and not the site. And, get ready for another Chrome update.

Related Stories: