{ "version": "https://jsonfeed.org/version/1.1", "title": "fboës - Der Blog | Artikel mit dem Tag \"Apache\"", "home_page_url": "https://journal.3960.org/", "feed_url": "https://journal.3960.org/tagged/apache/feed.json", "description": "Programmierung, Luft- & Raumfahrt, Kurioses: Der Blog von und mit Frank Boës.", "icon": "https://cdn.3960.org/favicon-192x192.png", "favicon": "https://cdn.3960.org/images/tile-128x128.png", "author": { "name": "Frank Boës", "url": "mailto:info@3960.org" }, "authors": [ { "name": "Frank Boës", "url": "mailto:info@3960.org" } ], "language": "de-DE", "_rss": { "about": "http://cyber.harvard.edu/rss/rss.html", "copyright": "© 2008-2023 Creative Commons BY" }, "items": [ { "id": "user/posts/2019-10-01-redirects-fuer-apache-verstehen/index.md", "url": "https://journal.3960.org/posts/2019-10-01-redirects-fuer-apache-verstehen/", "title": "Redirects für den Apache verstehen", "content_html": "
Nach größeren Änderungen an einem Internetauftritt gibt es oft den Wunsch, veraltete URLs auf neue URLs umzuleiten. Dazu kann man in Webservern sogenannte „Redirects“ anlegen – Umleitungen für URLs. Sowohl Besucher mit Lesezeichen wie auch Suchmaschinen werden so eure neuen Inhalte umgeleitet, auch wenn sie eine alte URL aufrufen.
\nFür den Apache Webserver gibt es 2½ Wege, wie man Redirects konfigurieren kann: redirect
, redirectmatch
sowie RewriteRule
. Tatsächlich ist die korrekte und fehlerfreie Konfiguration von Redirects aber eine trickreiche Sache – und ein genaues Studium der jeweiligen Anleitung notwendig, um Redirect Loops zu vermeiden.
Die 2½ verschiedenen Redirect-Direktiven funktionieren relativ ähnlich: Sie leiten eine Anfrage-URL, die einem bestimmten Muster entspricht, auf eine Ziel-URL um. Dazu können sie der Anfrage einen HTTP-Statuscode mitgeben, der den ursprünglichen Aufrufer mitteilt, aus welchem Grund und wie lange die Umleitung existiert.
\nDer Ort für die Konfiguration von Redirects ist entweder die Apache-Konfigurationsdatei, oder aber (wenn der Webserver dieses Feature eingeschaltet hat) die .htaccess
-Konfigurationsdatei direkt im Hosting-Verzeichnis bzw. der Document Root des Webauftritts.
Wenn kein Apache zum Einsatz kommt, funktioniert diese Methoden nicht – in der Regel verfügt aber jeder Webserver über eine zumindest ähnliche Methode, wie Redirects eingerichtet werden können.
\nBei der Einrichtung von Redirects sollte in der Konfigurationsdatei vermerkt werden, warum die Redirects eingerichtet wurden, oder wann sie gelöscht werden können. Nichts ist schlimmer, als in einem Wust von 6.500 Redirects nicht mehr durchzublicken und auch nicht zu wissen, ob nicht 6.000 Regeln schon lange hätten weggeworfen werden können. Hier bieten sich Kommentare an:
\n# Basic redirects START\nRedirect permanent "/index" "/"\n# Basic redirects END\n\n# SEO redirects DELETE AFTER 10/2020 START\nRedirect permanent "/artikel" "/articles"\nRedirect permanent "/kontakt" "/contact"\n# SEO redirects DELETE AFTER 10/2020 END\n
\nGerade bei Redirects, die Suchmaschinen von einer alten, nicht mehr im Einsatz befindlichen URL auf eine neue URL umleiten sollen, kann nach zwei Jahren spätestens davon ausgegangen werden, dass sie nicht mehr notwendig sind.
\nEin weiterer Vorschlag ist, die Direktiven für Redirects in Blöcke einzupacken, die testen, ob das für die Direktiven notwendige Modul überhaupt installiert ist:
\n<IfModule mod_alias.c>\n Redirect permanent "/index" "/"\n</IfModule>\n\n<IfModule mod_rewrite.c>\n RewriteRule "^/source$" "/target" [R=301,L]\n</IfModule>\n
\nDies verhindert, dass der Webserver seinen Betrieb einstellt, falls das Modul deaktiviert wird. Andersherum kann man diese Blöcke natürlich weglassen, wenn man explizit möchte, dass das Deaktivieren von Modulen und der damit verbundenen Redirects auffällt. 😉
\nWenn man sich die Anleitung für mod_alias
inklusive redirect
und redirectmatch
sowie die Anleitung für mod_rewrite
inklusive RewriteRule
genau anschaut, wird man überraschenderweise darauf stoßen, dass alle Varianten bei der Anfrage-URL nicht eine fixe URL entgegen nehmen, sondern ein Muster (bzw. Pattern). Diese Muster erwischen meistens mehr Anfrage-URLs, als man auf den ersten Blick vermuten möchte.
Selbst die harmlos wirkende Redirect
-Direktive sucht nach einem Muster (und nicht nach einem festen Wert), und hängt alle überschüssigen URL-Teile inklusive GET
-Parameter an die Ziel-URL an:
Redirect permanent "/source" "/target"\n# Redirects /source to /target\n# Redirects /source123 to /target123\n# Redirects /source/12 to /target/12\n# Redirects /source/?a to /target/?a\n
\nDas stellt eine größere Quelle für Verwirrung dar, da ein unbedarfter Einrichter mit der obigen Direktive nicht eine einzige Anfrage-URL umleitet, sondern tatsächlich eine unüberschaubar große Menge. Zudem kann eine frühere Regel nachfolgende Regeln unbenutzbar machen, ohne dass dies auf den ersten Blick auffällt:
\nRedirect permanent "/source" "/target"\nRedirect permanent "/source/12" "/target/some-special-place"\n\n# Redirects /source to /target\n# Redirects /source123 to /target123\n# Redirects /source/12 to /target/12 (!)\n# Redirects /source/?a to /target/?a\n
\nVerständlicher ist dort die RedirectMatch
-Direktive, die von vorne herein mitteilt, dass sie mittels eines regulären Ausdrucks die Anfrage-URL in eine Ziel-URL umformt. Bei einer Fehlbedienung sind die Konsequenzen aber noch viel weitreichender:
RedirectMatch permanent "/source" "/target"\n# Redirects /source to /target\n# Redirects /source123 to /target\n# Redirects /source/12 to /target\n# Redirects /source/?a to /target\n# Redirects /your-shiny/source/?a to /target\n
\nEine Entsprechung zu RedirectMatch
findet sich bei mod_rewrite
, das auch kompliziertere Umleitungen abbilden kann.
Die RewriteRule
-Direktive hat entsprechende Fallstricke im Angebot, da sie ebenfalls mit regulären Ausdrücken arbeitet und je nach Einsatzort ein anderes Matching verwendet:
Die Einschränkung für .htaccess
-Dateien kann übrigens mit einem vorangestellten RewriteCond %{REQUEST_URI}
aufgehoben werden, so dass sich die Regeln wieder analog zu ihrem Aufruf innerhalb einer <VirtualHost>
-Direktive verhalten.
Damit sehen die Matches wie folgt aus:
\nRewriteRule "/source" "/target" [R=301,L]\n# Redirects /source to /target\n# Redirects /source123 to /target\n# Redirects /source/12 to /target\n# Redirects /source/?a to /target\n# Redirects /your-shiny/source/?a to /target\n
\nDie Gefährlichkeit von Redirect
wird dann offenbar, wenn man seine Funktionalität mit RedirectMatch
und RewriteRule
nachbaut. Denn tatsächlich benutzt Redirect
implizit ein nicht wenig komplexes Pattern-Matching. Folgendes Beispiel zeigt, wie inhaltlich identische Regeln teilweise sehr unschuldig aussehen können:
Redirect permanent "/source" "/target"\nRedirectMatch permanent "^/source(.*)" "/target$1"\nRewriteRule "^/source(.*)" "/target$1" [R=301,L]\n
\nUm sich komplett sicher zu sein, von wo nach wo Redirects erzeugt werden, sollten nur die Redirect-Direktiven mit regulären Ausdrücken verwendet werden. Diese weisen von vorne herein darauf hin, dass ihre Konfiguration wohl überlegt sein möchte. Dabei helfen die Steuerzeichen für PCREs bzw. Perl-kompatible reguläre Ausdrücke:
\n^
: Stimmt mit dem Anfang einer Zeichenkette überein.$
: Stimmt mit dem Ende einer Zeichenkette überein.?
: Das Zeichen bzw. die Gruppe vor dem ?
ist optional.Ein super-einfacher, direkter Redirect von exakt einer Anfrage-URL auf exakt eine Ziel-URL kann mittels Umschließung mit ^…$
realisiert werden:
RewriteEngine On\nRewriteCond %{REQUEST_URI}\nRewriteRule "^/source$" "/target" [R=301,L]\n# Redirects /source to /target\n
\nWenn Anfrage-URLs ohne und mit abschließenden /
erlaubt sein sollen, kann dieses Muster um ein optionales /
erweitert werden:
RewriteEngine On\nRewriteCond %{REQUEST_URI}\nRewriteRule "^/source(/)?$" "/target$1" [R=301,L]\n# Redirects /source to /target\n# Redirects /source/ to /target/\n
\nWenn ganze URL-Bereiche auf eine Ziel-URL umgeleitet werden sollen, kann der letzte Teil der URL explizit mit einem Muster erfasst werden. .*
erfasst bei regulären Ausdrücken eine beliebige Anzahl von beliebigen Zeichen:
RewriteEngine On\nRewriteCond %{REQUEST_URI}\nRewriteRule "^/source/.*$" "/target/" [R=301,L]\n# Redirects /source/ to /target/\n# Redirects /source/example to /target/\n# Redirects /source/?abc to /target/\n
\nUnd nicht zuletzt kann ein ganzer Bereich auch 1:1 auf einen anderen Bereich umgeleitet werden, indem man die überschüssigen URL-Teile der Anfrage-URL an die Ziel-URL weiterleitet:
\nRewriteEngine On\nRewriteCond %{REQUEST_URI}\nRewriteRule "^/source/(.*)$" "/target/$1" [R=301,L]\n# Redirects /source/ to /target/\n# Redirects /source/example to /target/example\n# Redirects /source/?abc to /target/?abc\n
\nDer nginx-Webserver erfreut sich stetig wachsender Beliebtheit, und verfügt über ähnliche Methoden namens rewrite
zum Erzeugen von Redirects. Entsprechend sieht das letzte Beispiel für den Apache im nginx wie folgt aus:
rewrite ^/source/(.*)$ /target/$1 permanent\n# Redirects /source/ to /target/\n# Redirects /source/example to /target/example\n# Redirects /source/?abc to /target/?abc\n
\nEine besonders geniale Lösung für nginx-Redirects auf Stackoverflow schmeißt aber die gesamte Denkarbeit über Bord, und erlaubt tatsächlich das Anlegen einer einfachen Tabelle von Anfrage- und Ziel-URLs.
\nDie Einrichtung von Redirects im Apache-Webserver kann schnell unbeabsichtigte Folgen heraufbeschwören, und sogar den gefürchteten Redirect-Loop mit seiner bekannten Fehlermeldung „Too many redirects“ provozieren. Die Einrichtung mit Augenmaß und das Studium der Anleitung bewahrt euch davor, euren Internetauftritt unerreichbar zu machen.
\nFalls ihr Wünsche für Redirects in Form einer Liste „Anfrage → Ziel“ erhaltet, dürft ihr diese Liste nicht 1:1 in eure Redirect-Direktiven umwandeln, sondern solltet mit den obigen Beispielen eine präzisere Übersetzung durchführen.
", "summary": "Nach größeren Änderungen an einem Internetauftritt gibt es oft den Wunsch, veraltete URLs auf neue URLs umzuleiten. Dazu kann man in Webservern sogenannte …", "date_published": "2019-10-01T18:03:10+02:00", "date_modified": "2020-01-06T12:37:22+01:00", "author": { "name": "Frank Boës", "url": "mailto:info@3960.org", "avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca" }, "authors": [ { "name": "Frank Boës", "url": "mailto:info@3960.org", "avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca" } ], "banner_image": "https://cdn.3960.org/favicon-192x192.png", "language": "de-DE", "image": "https://cdn.3960.org/favicon-192x192.png", "tags": [ "Programmierung", "Webdevelop", "Apache" ] }, { "id": "user/posts/eine-mini-checkliste-fur-das-neue-cms.md", "url": "https://journal.3960.org/posts/eine-mini-checkliste-fur-das-neue-cms/", "title": "Eine Mini-Checkliste für ein neues CMS unter einer alten Domain", "content_html": "Ab und an müsst ihr unter einer bereits existierenden Domain ein neues CMS installieren. Dadurch werden URLs geändert, und Besucher mit alten URLs stehen auf einmal im Regen. Diese kleine Liste listet die wichtigsten Handgriffe auf, die man vorbereiten sollte.
\n\nPrivat durchexerziert habe ich den Fall neulich erst, als ich von einem alten Grav-CMS auf meinen Static Site Generator „Blogophon“ umgestellt habe.
\nNach dem Einspielen eines neuen CMS' sind möglicherweise eure URLs nicht mehr die selben. Das könnte damit zu tun haben, dass ihr komplett neue Inhalte anlegen wollt. Oder ihr wollt zwar die alten Inhalte übernehmen, aber durch das neue CMS können die alten URLs nicht mehr verwendet werden.
\nDas ganze ist für Leute ein Problem, die noch alte Links zu eurer alten Seite haben. Das können Lesezeichen sein, URLs aus alten Newslettern, oder durch Suchmaschinen indizierte Links. Durch Änderung der URLs kriegen sie eine 404
-Fehlermeldung.
Gerade in Bezug auf Suchmaschinen ist es ja ärgerlich, Besucher zu verprellen, die nur schnell auf ein Suchergebnis geklickt haben. Hier also ein paar schnelle Schritte, um zumindest den größten Ärger abzuwehren:
\nMacht euch ein möglichst genaues Bild über die Lage, indem ihr eine Liste eurer alten URLs anlegt. Dies kann mittels eines access.log
des Webservers geschehen – oder über die Methode, bei Google die unter eurer Domain erfassten URLs anzuzeigen. Für die Domain journal.3960.org
geht das z.B. via https://www.google.de/?q=site%3Ajournal.3960.org
Versucht nun möglichst, die alten URLs beizubehalten. In Fällen, wo dies nicht möglich ist, sind folgende HTTP-Statuscodes sinnvoll, die ihr in eurem Webserver anlegt (bzw. mittels htaccess
):
301 Moved Permanently
-Weiterleitung von alten URLs auf dazu passende neue URLs. Damit wissen Browser wie auch Suchmaschinen, dass der alte Inhalt dauerhaft umgezogen ist. U.a. kann man auch viele alte URLs mittels eines regulären Ausdrucks auf eine neue URL umlenken. Bei vielen alten Artikeln in einer Rubrik kann man so zumindest auf die neue Rubrik umleiten.410 Gone
-Statuscode für alte URLs, die es nie wieder geben wird. So könnt ihr diese schnell dauerhaft aus Suchindexen entfernen.404 Not found
-Statuscode erzeugen werden, sollte unbedingt die 404-Seite eingebaut und mit hilfreichen Informationen gefüttert werden. Z.B. kann dort gleich die seiteninterne Suche prominent platziert werden, oder Links zu den wichtigsten Artikeln.Nicht zuletzt hat die korrekte Pflege von 301
- und 410
-Tabellen für euren Webserver den Vorteil, dass er nicht den relativ aufwändigen 404
-Fall durchknobeln muss.
Darüber hinaus sollte man auch schnell Suchmaschinen mit neuem Futter versorgen, und folgende Dokumente pflegen:
\nsitemap.xml
sollte eure neuen URLs auflisten.robots.txt
sollte auf eure neue Sitemap verweisen.Oh, und wenn ihr gerade dabei seid, Suchmaschinen mit neuen Inhalten zu bedenken:
\n<title />
und eine <meta name=„description“ />
vorhanden ist.Als Nachbereitung sollte man regelmäßig das error.log
des Webservers überprüfen, um 404
-Fälle zu finden und ggf. durch schlaue Webserver-Direktiven umzulenken.
Ein neues CMS unter einer bereits existierenden Domain bedarf einiger Vorbereitung. Mit ein bisschen Webserver-Magie kann man aber für Besucher und Suchmaschinen die Umstellung sehr reibungslos gestalten, und wieder schnell seinen Suchindex auffüllen.
", "summary": "Ab und an müsst ihr unter einer bereits existierenden Domain ein neues CMS installieren. Dadurch werden URLs geändert, und Besucher mit alten URLs stehen auf…", "date_published": "2016-08-12T19:18:41+02:00", "date_modified": "2019-10-06T08:57:02+02:00", "author": { "name": "Frank Boës", "url": "mailto:info@3960.org", "avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca" }, "authors": [ { "name": "Frank Boës", "url": "mailto:info@3960.org", "avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca" } ], "banner_image": "https://cdn.3960.org/favicon-192x192.png", "language": "de-DE", "image": "https://cdn.3960.org/favicon-192x192.png", "tags": [ "Programmierung", "Anleitung", "CMS", "Webdevelop", "Apache" ] } ] }