Das Putzlowitsch Test- und SEO-Blog

WordPress 2.3 – Problem ohne www bei Strato

Hintergrund

Es war mir ja schon fast am Anfang meiner Strato-Zeit aufgefallen. Die Servervariable HTTP_HOST liefert immer den Hostname mit einem vorangestellten www zurück, selbst dann, wenn der Aufruf ohne www erfolgte. Eigentlich eine eigenwillige, wenn nicht gar falsche Konfiguration des Strato-Severs, denn die Variable HTTP_HOST soll eigentlich genau das enthalten, was der Browser im HTTP-Requestheader übermittelt. Wenn ich also die Seite schnurpsel.de aufrufe, dann sollte eben das da drin stehen, und nicht etwa www.schnurpsel.de. Aber genau das passiert bei Strato (PowerWeb A und S).

Problem

Bisher stellte das auch kein Problem dar, mit dem Neuen WordPress 2.3 aber schon (deshalb war meine Seite gestern Abend auch zeitweise nicht erreichbar). Ab WordPress 2.3 ist eine Funktion integriert, die ein sogenanntes „Canonical Redirect“ ausführt. Auf das Strato-Problem bezogen bedeutet das, daß eine Weiterleitung z.B. dann stattfindet, wenn der Aufruf der Seite nicht so erfolgt, wie das in der WordPresskonfiguration eingestellt ist.
Wenn z.B in WordPress als Blog-Adresse (URL)

http://schnurpsel.de

eingetragen ist, jemand aber die Seite mit

http://www.schnurpsel.de

aufruft, wird er auf

http://schnurpsel.de

umgeleitet (und anders rum). An sich eine sinnvolle Sache, gerade unter SEO-Aspekten.

Was passiert nun aber bei Strato? Die funktion redirect_canonical schaut in HTTP_HOST nach, wie die Seite aufgerufen wurde, stellt fest, daß da ein www steht, aber das Blog ohne www konfiguriert ist. Also wird flux auf die Adresse ohne www weitergeleitet (diese Information bekommt der Browser zurück). Der ruft dann brav die Seite erneut ohne www auf, weil aber Strato das www wieder vorneran stellt, leitet redirect_canonical erneut um, der Browser ruft wieder brav ohne www auf usw. usw. Es ensteht also eine Weiterleitungs-Endlosschleife, die der Browser dann aber (hoffentlich) nach ein paar Versuchen mit einer Meldung beenden sollt. Beim Firefox sieht das dann so aus:

Fehler: Umleitungsfehler
Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann.

Das alles tritt aber nur beim Blog selber auf, der Adminbereich ist davon nicht betroffen.

Lösung

Aber auch hier gibt es mit einem bißchen Basteln Abhilfe. Glücklicherweise gibt es in den Servervariablen einen Eintrag, der die tatsächlich aufgerufene Adresse enthält, nämlich SCRIPT_URI. Dieser enthält die vollständigen Aufrufadresse mit http und gegebenfalls Verzeichnis und Dateiname, z.B.

http://schnurpsel.de

Hier kann man einfach den echten Hostanamen extrahieren und der Variable HTTP_HOST zuweisen. Und schon ist die Welt wieder in Ordnung :-)

Also WordPress-Plugin sehen die paar Zeilen PHP-Code dann so aus:

<?php
/*
Plugin Name: 123 True HTTP Host
Plugin URI: http://schnurpsel.de/wordpress-23-problem-ohne-www-bei-strato-65/
Description: Setzt den wahren HTTP_HOST aus dem Request. Bei Strato wird immer www davor geschrieben.
Author: Ingo Henze
Version: 0.10
Author URI: http://putzlowitsch.de/
*/ 
$plw123thh = parse_url( $_SERVER['SCRIPT_URI'] );
if( isset( $plw123thh['host'] ) && ($plw123thh['host']!=$_SERVER['HTTP_HOST']) )
  $_SERVER['HTTP_HOST'] = $plw123thh['host'];
?>

Mann kann den Quelltext hier einfach rauskopieren, in einer Datei speichern,auf den Server in das Pluginverzeichnis kopieren und aktivieren. Oder man nimmt das fertige Plugin als ZIP-Datei.

Download: 123 True HTTP Host 0.10

Im Übrigen tritt das Problem mit der Weiterleitungs-Endlosschleife bei einer Konfiguration mit www nicht auf, allerdings funktioniert dann das redirect_canonical auch nicht, weil die Seiten ja scheinbar immer korrekt mit www aufgerufen werde.

116 Kommentare »

Logfile-Kunst

Nach der Pixelkunst habe ich heute in meinem Server-Logfile folgendes entdeckt:

"GET /themen/wordpress/ HTTP/1.1" 301 5
"GET /themen/wordpress// HTTP/1.1" 301 5
"GET /themen/wordpress/// HTTP/1.1" 301 5
"GET /themen/wordpress//// HTTP/1.1" 301 5
"GET /themen/wordpress///// HTTP/1.1" 301 5
"GET /themen/wordpress////// HTTP/1.1" 301 5
"GET /themen/wordpress/////// HTTP/1.1" 301 5
"GET /themen/wordpress//////// HTTP/1.1" 301 5
"GET /themen/wordpress///////// HTTP/1.1" 301 5
"GET /themen/wordpress////////// HTTP/1.1" 301 5
"GET /themen/wordpress/////////// HTTP/1.1" 301 5
"GET /themen/wordpress//////////// HTTP/1.1" 301 5
"GET /themen/wordpress///////////// HTTP/1.1" 301 5
"GET /themen/wordpress////////////// HTTP/1.1" 301 5
"GET /themen/wordpress/////////////// HTTP/1.1" 301 5
"GET /themen/wordpress//////////////// HTTP/1.1" 301 5
"GET /themen/wordpress///////////////// HTTP/1.1" 301 5
"GET /themen/wordpress////////////////// HTTP/1.1" 301 5
"GET /themen/wordpress/////////////////// HTTP/1.1" 301 5
"GET /themen/wordpress//////////////////// HTTP/1.1" 301 5
"GET /themen/wordpress///////////////////// HTTP/1.1" 301 5

Gut, hinten und vorn habe ich einiges weggelassen aber auch so sieht das doch sehr nett aus. Zumal es dann öfter im Logfile stand, manchmal auch etwas kleiner.

Und wie der erfahrene Webmaster am Statuscode 301 sofort erkennt, handelt es sich um eine Redirect-Endlosschleife, also um theoretisch unendlich viele permanente Weiterleitungen. Das es nicht tatsächlich endlos so weitergeht liegt nur daran, daß der ordentlich programmierte Browser/Robot/Bot nach einer gewissen Anzahl Redirects das Spielchen nicht mehr mitmacht und mit einer Fehlermeldung dem Spuk ein Ende setzt. Bei Firefox und Opera sind es z.B. 20 Weiterleitungen, der Google-Bot gibt bereits nach 5 Versuchen auf. Am hartnäckigsten ist der MS-Internetexplorer 6, er läßt sich stolze 100 mal Umleiten.

Wie kommts? Ich hatte im Zuge der Abschaltung der Verbindestrichung und HTML-Terminierung beschlossen, die alten URLs per Redirect auf die aktuelle weiterzuleiten, hatte aber einen kleinen Fehler in meinem regulären Ausdruck bei den Kategorien, es fehlte ein Bindestrich. So wurden auch die gültigen Themenseiten mit einem angehängten Schrägstrich weitergeleitet, weitergeleitet und weitergeleitet. Wenn ein Browser oder Bot keinen Weiterleitungszähler verwendet, würde wohl irgendwann der Webserver mit einem ‚414 Request-URI Too Long‘ das Handtuch werfen.

Und die Moral von der Geschicht: „Verendlosschleife Redirects niemals nicht!“ :-)

Keine Kommentare »