Ein irres Problem mit dem Redirect (Umleitung) von Apache – leitet auf www.www

17 Juni 2017 9 Kommentare Autor: Jürgen (jdo)

Ich habe meine Website auf einen eigenen root-Server mit Linux umgezogen und gestern von mehreren Leuten den Hinweis bekommen, dass ein Redirect oder eine Umleitung nicht so funktioniert wie es oder sie soll. Vielen Dank dafür!!!

Ich verstehe das Problem immer noch nicht und es ist derzeit nur ein Workaround am Laufen. Ich beschreibe das Problem mal und vielleicht kann mir jemand helfen.

Redirects wurden getestet

Vor dem Umzug auf den VPS habe ich eine schlafende Domain dort hingezogen und ausprobiert, wie das mit Apache und so weiter funktioniert. Da klappt es auch, bei bitblokes.de nicht. Hier was ich für beide Domains gemacht habe:

  • Bei Strato liegt die Domain, zeigt aber mit einem A-Record auf den root-Server.
  • Es gibt einen Virtual Host für die Domain angelegt
  • Mit Certbot ein Zertifikat geholt
  • Angegeben, dass alle Zugriffe auf https umgeleitet werden sollen
  • Eine Umleitung / einen Redirect angelegt, dass alle nicht-www-Zugriffe auf www umgeleitet werden sollen.

Das passiert nun

Rufe ich die eine Domain über http://www.<name>.dewww.<name>.de, https://<name>.de auf, werden alle drei Aufrufe brav auf https://www.<name>.de umgeleitet.

Mache ich das mit bitblokes.de, dann funktioniert die Umleitung nur bei https://bitblokes.de und http://bitblokes.de. Gebe ich aber http://www.bitblokes.de ein, dann macht mit das doofe System daraus https://www.www.bitblokes.de und ich finde den Fehler nicht.

Ich habe schon die .htaccess der anderen Domain auf bitblokes.de kopiert und nur den Domänennamen angepasst. Neustart, service apache2 reload und der ganze Mist nutzen alles nichts. Das System leitet immer auf https://www.www.bitblokes.de um.

Redirect springt auf www.www

Redirect springt auf www.www

Eine Recherche im Internet hat sich eher als mager erwiesen. Ich habe an ganz wenigen Stellen gefunden, dass einige das Problem erwähnen – zum Beispiel bei stackoverflow. Aber auch diese Lösung führt bei mir nicht zum gewünschten Erfolg.

Redirect des Certbot

Der Certbot oder Let’s Encrypt macht folgenden Eintrag im Virtual Host (vor dem abschließenden </VirtualHost>):

RewriteEngine on
RewriteCond %{SERVER_NAME} =bitblokes.de [OR]
RewriteCond %{SERVER_NAME} =www.bitblokes.de
RewriteRule ^ https://www.%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Sowohl in der funktionierenden Domain als auch in der .htaccess-Datei von bitblokes.de befindet sich am Anfang noch dieses Schnipsel.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.bitblokes.de/$1 [L,R=301]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.bitblokes.de/$1 [L,R=301]
</IfModule>

Wobei es völlig irrelevant ist, ob ich das rauslasse oder einfüge und ich habe auch schon dutzende andere Beispiele ausprobiert, die ich so im Internet gefunden habe. Das Ergebnis bleibt gleich.

Kruder Workaround für den Redirect oder die Umleitung

Was bisher als einzige Lösung funktioniert, ist eine Umleitung vor dem Redirect, den Let’s Encrypt eingerichtet hat. Ganz ideal ist das nicht, aber es kommt kein Fehler und ist ebenfalls nur eine Umleitung. Leite ich Zugriffe von http://www.bitblokes.de direkt auf https://www.bitblokes.de vor allen andere Umleitungen, dann klappt es. Bei der anderen Domain ist das nicht notwendig und ich frage mich, warum das so ist:

Mein Virtual Host sieht am Ende nun so aus:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.bitblokes\.de [NC]
RewriteRule ^(.*)$ https://www.bitblokes.de/$1 [L,R=301]
RewriteCond %{SERVER_NAME} =bitblokes.de [OR]
RewriteCond %{SERVER_NAME} =www.bitblokes.de
RewriteRule ^ https://www.%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Das funktioniert – nachdem ich den Cache und die Cookies im Browser gelöscht habe. Der merkt sich alte Umleitungen dummerweise auch noch.

  1. Hilft das vielleicht jemand anderem, der ebenfalls Probleme mit einer Umleitung oder einen Redirect auf www.www hat.
  2. Hat jemand schon so ein ähnliches Problem gehabt und kann mir erklären, woran das liegt oder was ich falsch gemacht habe? Bei der anderen Domain funktioniert es auch und die Einrichtung war identisch.

Möglicherweise stehe ich auch komplett auf dem Schlauch und sehe vor lauter Umzug den Wald vor lauter Bäumen nicht. Ich bin im Moment auf jeden Fall erst einmal froh, dass es funktioniert. Ich würde es aber trotzdem gerne verstehen.

Wie teste ich die Redirects oder Umleitung? Kann ich das verfolgen?

Ja, das geht und zwar mit curl. Der nachfolgende Befehl zeigt Dir genau, was der Browser so empfängt und wann welche Umleitung zieht.

curl --verbose --head --location http://www.bitblokes.de

Das ist recht praktisch, wenn Du einen Redirect verfolgen oder debuggen willst. Mit curl und dem Befehl oben kannst Du alle möglichen Kombinationen testen und nachsehen, ob Dir das Ergebnis taugt. Dabei kann Dir der Cache im Browser auch keinen Strich durch die Rechnung machen.

Du kannst gerne Deinen Senf zu diesem Beitrag geben: Hier geht es zu den Kommentaren




Schreiben macht durstig! Eine kleine Erfrischung kann daher nie schaden. Wem dieser freie Artikel gefallen hat, der darf mir gerne einen frisch gezapften Hopfen-Tee ausgeben (Paypal - der Spenden-Knopf
)
oder

Bitcoin-Adresse: 1NacVNwcLLePUVv8uSafu5Ykdwh8QyDfgK

Ethereum-Adresse: 0x9cc684575721dc07b629ad5d81b43ab4b992e76e

Verge-Adresse: DJaJtZeW494xhnRJJt19Lnt2R5pz7zRp5A

Ich freue mich über jede noch so kleine Spende. Vielen Dank und Prost!

 
 Alle Kommentare als Feed abonnieren

9 Kommentare zu “Ein irres Problem mit dem Redirect (Umleitung) von Apache – leitet auf www.www”

  1. Schroeffu sagt:

    Was steht denn bei "ServerName" und "ServerAlias" zu Beginn in der *.conf?

    Bei dir müsste m.E. stehen
    ServerName bitblokes.de
    ServerAlias http://www.bitblokes.de

    Viele machen das gerade anders herum aber das ist denke ich "falscher" (www. ist auch im Lets Encrypt Zertifikat nur ein Alias), vielleicht einfach mal ausprobieren 🙂

  2. Schroeffu sagt:

    Noch ein Hinweis, der mir eben eingefallen ist: Eigentlich braucht es für WordPress in der Apache site.conf keine extra Umleitung non-www nach http://www., das macht WordPress selbst. Dazu einfach die SiteUrl in den Apache Einstellungen auf entweder http://www.domain.de oder nur domain.de Einstellen.

    Ich persönlich mag es, bei IT-Webseiten das www weglassen, diese Besucher wissen dass www. überflüssig ist.
    Hingegen eine Website die sich beispielsweise um ein Restaurant handelt, macht www. Sinn, da hier die Kundschaft noch heute denkt www. gehört zu einer Webadresse dazu 🙂

    • jdo sagt:

      hm? Bei mir hat das WordPress noch nie selbst gemacht. Vorher konnte ich die Seite sowohl mit als auch ohne www erreichen.

      Das www ist halt schon immer drin und da gibt es einige Sachen, die ich ändern müsste, was nicht mit einer Umleitung funktioniert. Eine Altlast und auf eine Umstellung habe ich keine große Lust.

  3. Jens sagt:

    Das allererste Beispiel zeigt doch schon das Problem: wenn Server-Name gleich bitblokes.de oder wenn Server-Name gleich http://www.bitblokes.de ist, dann leite um zu http://www.%{SERVER_NAME}... Jetzt setz mal für Server-Name http://www.bitblokes.de ein: http://www.www.bitblokes.de.

    Ich würde certbot da nichts automatisch machen lassen und die Rewrites manuell und nur an einer Stelle einstellen.

  4. Malte sagt:

    Also für mich ist das beschriebene Verhalten genau das was ich auch erwarten würde, in beiden Fällen.
    Mit RewriteCond %{SERVER_NAME} =bitblokes.de [OR] und RewriteCond %{SERVER_NAME} =www.bitblokes.de matchst du ja beide Fälle, sowohl mit als auch ohne www. Und dann packst du vorne noch ein www. davor. Ich hab das gerade bei kurz getestet und das Phänomen tritt auch auf.

    Mit deinem Workaround RewriteCond %{HTTP_HOST} ^www\.bitblokes\.de [NC] testest du ja ob der Host mit www anfängt und leitest in diesem Fall um auf die https Variante. Mit dem L als Flag ignoriert er dann die folgenden Regeln.

    Ohne es getestet zu haben sollte das Snippet mit dem Ifmodule alleine ausreichen. Deaktiviere das andere einmal (Wenn eine Umleitung daraus greift und es weiter oben steht, evaluiert er den Rest nicht mehr, wegen dem L).
    Außerdem würde ich immer mit temporären Umleitungen testen, da sich die permanenten tatsächlich im Browser festsetzen. Dann hilft nur warten.

Antworten