Update #1: Es war weniger schlimm als erwartet, Details siehe unten.
Update #2: Chrome wurde aktualisiert, der HTTPS-Header ist verschwunden, Details siehe unten.
Das ist interessant: Mit der Veröffentlichung von Chrome 44 (Version 44.0.2403.89), die erst gestern erfolgte, scheint der Browser einen kleinen Fehler oder eine signifikante Änderung eingeführt zu haben. Standardmäßig sendet Chrome nun den HTTPS: 1-Header bei jeder Anfrage mit. Dies war wahrscheinlich als Sicherheitsverbesserung gedacht, um HTTPS dem Server wo immer möglich vorzuschlagen, legt aber WordPress und andere Webserver-Installationen lahm.
Der Grund? Die meisten PHP-Anwendungen nutzen $_SERVER['HTTPS'];, um zu erkennen, ob die Webseite über ein SSL-Zertifikat läuft oder nicht. Dies betrifft WordPress, Drupal und jede kundenspezifische PHP-Software, die diesen Header prüft.
if ($_SERVER['HTTPS'] || $_SERVER['HTTP_HTTPS']) { // HTTPs annehmen, weiterleiten oder https:// Präfixe für alle Ressourcen (css/js/images/...) aktivieren ... }Die nächste geplante Chrome-Veröffentlichung ist für den 27. Juli angesetzt, aber es wird geprüft, ob ein Notfall-Patch zur Behebung dieses Problems herausgegeben werden kann.
Bugtracker: Issue 505268: Forcing WordPress sites to use https even when not directed.
Dies verspricht keine angenehme Woche für Nutzer von Chrome44 zu werden.
Update #1: Nur HTTP_ präfixierte Header waren betroffen
Jeder Request-Header, den ein Browser sendet, wird in der globalen Variable $_SERVER mit HTTP_ präfixiert. Der User-Agent wird zu HTTP_USER_AGENT, der Accept-Header wird zu HTTP_ACCEPT, und so weiter.
So sehen diese HTTP-Header laut PHP aus:
print_r($_SERVER);
Array
(
...
[HTTPS] => on
[HTTP_HOST] => ma.ttias.be
[HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
[HTTP_ACCEPT_ENCODING] => gzip, deflate, sdch
[HTTP_ACCEPT_LANGUAGE] => nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4,fr;q=0.2,it;q=0.2
[HTTP_COOKIE] => some=value
[HTTP_HTTPS] => 1
[HTTP_USER_AGENT] => Mozilla/5.0
)Der erste HTTPS-Wert in der $_SERVER-Variable wird vom Webserver gesetzt, um HTTPS anzuzeigen oder nicht. Der zweite, HTTP_HTTPS, ist der vom Chrome-Browser gesendete HTTPS-Header, der für PHP in eine Variable umgewandelt wird.
Einige PHP-Codes, wie das WooCommerce WordPress-Plugin, prüften nicht nur $_SERVER['HTTPS'], sondern auch $_SERVER['HTTP_HTTPS'], um HTTPS auf der Seite zu erkennen. Dies ist eine fehlerhafte PHP-Implementierung und hat nichts mit “schlechtem PHP-Design” zu tun.
Die HTTP_-Präfix-Behandlung durch WooCommerce ist wahrscheinlich das Ergebnis eines einst existierenden Apache-Bugs/Features, bei dem nach 301/302 HTTP-Weiterleitungen einige Umgebungsvariablen immer mit einem weiteren HTTP_-Schlüsselwort präfixiert wurden.
Es gibt auch Reverse-Proxy-Konfigurationen (Nginx, Varnish, …), die ebenfalls Umgebungsvariablen weitergeben, die von Apache als Header interpretiert werden und somit das HTTP_-Präfix erhalten.
In jedem Fall haben die meisten Plugins inzwischen ein Update erhalten. Gehen Sie einfach auf Ihre WordPress-/Drupal-/…-Seite und aktualisieren Sie alle Plugins. Die Chancen stehen gut, dass die Probleme behoben sind, auch wenn Chrome noch ein paar Tage braucht, um den Patch zu veröffentlichen.
Spezifische Lösung für WooCommerce
Die meisten Probleme wurden von WooCommerce, dem WordPress-Plugin, gemeldet. Da die Wahrscheinlichkeit groß ist, dass Sie sich nicht mehr in Ihr WordPress einloggen können, benötigen Sie eine andere Lösung. Vielen Dank an Rahul Lohakare in den Kommentaren für diesen Fix.
Ändern Sie die folgende Datei, laden Sie sie entweder per FTP herunter und wieder hoch oder bearbeiten Sie sie direkt auf dem Server: wp-contentpluginswoocommercewoocommerce.php
Kommentieren Sie diese Zeilen aus:
if ( ! isset( $_SERVER['HTTPS'] ) && ! empty( $_SERVER['HTTP_HTTPS'] ) ) {
$_SERVER['HTTPS'] = $_SERVER['HTTP_HTTPS'];
}Sobald diese Zeilen auskommentiert sind (einfach jede Zeile mit einem # präfixieren), leitet WooCommerce/WordPress Sie nicht mehr um.
Falls dies immer noch nicht funktioniert, verwenden Sie Firefox oder einen anderen Browser, um sich auf Ihrer Webseite anzumelden und das Plugin über die offizielle WordPress-Update-Methode zu aktualisieren. Da das Problem nur Chrome betrifft, können Sie die Umleitung vorübergehend umgehen, indem Sie einen anderen Browser verwenden.
Update #2: Chrome wurde aktualisiert, ‘HTTPS’ durch ‘upgrade-insecure-requests’ ersetzt
Chrome hat ein Update veröffentlicht, das jeder innerhalb weniger Stunden erhalten sollte. Ich bin jetzt auf Version 44.0.2403.107, alles Höhere wird dieses Problem nicht mehr haben.
Screenshot der Chrome-Browserversion 44.0.2403.107 nach dem Update zur Behebung des HTTPS-Header-Problems
Nach dem Update wurde der HTTPS-Header durch den upgrade-insecure-requests-Header ersetzt.
Gute Nachrichten für alle!
Zusammenfassend lässt sich sagen, dass der chrome44-Bug, der durch das ungewollte Senden des HTTPS: 1-Headers verursacht wurde und zahlreiche PHP-Anwendungen beeinträchtigte, erfolgreich behoben ist. Es ist stets ratsam, Ihre Browser und Plugins auf dem neuesten Stand zu halten, um solche Kompatibilitätsprobleme zu vermeiden und die Sicherheit Ihrer Webseite zu gewährleisten. Überprüfen Sie Ihre Chrome-Version und stellen Sie sicher, dass Sie von diesem Fix profitieren.