Eine Herausforderung, mit der viele Drupal-Sitebuilder und -Entwickler konfrontiert sind, ist die Suche nach der Quelle einer unerwünschten HTTP 301- oder 302-Weiterleitung, die verhindert, dass Besucher/innen über das Internet auf die Inhalte ihrer Website zugreifen können. Die Stelle im Code oder in der Konfiguration deiner Website zu finden, an der diese unerwünschte Weiterleitung ausgelöst wird, kann eine schwierige und frustrierende Aufgabe sein. In dieser Anleitung stellen wir dir ein paar Techniken vor, mit denen du die möglichen Ursachen für 301- und 302-Weiterleitungen auf deiner Website ausschließen oder eingrenzen kannst.
1. Verwende die richtigen Debugging-Tools.
Unsere erste Empfehlung für die Fehlersuche lautet, ein Tool zu verwenden, mit dem du
- Untersuche die Antwort-Header, die vom Server gesendet werden, wenn diese Weiterleitungen auftreten.
- Verfolge mehrere Weiterleitungen
Wenn du dich mit der Kommandozeile auskennst, stehen dir unter anderem die folgenden Tools zur Verfügung:
- cURL, mit den Optionen „-L“ (Weiterleitungen verfolgen) und „-IX GET“ (eine GET-Anfrage senden, aber nur die Kopfzeilen der Antwort anzeigen, nicht den Antworttext).
- Wget, mit der Ausgabe „-qSO /dev/null“ (alle Ausgaben außer den Antwortkopfzeilen des Servers unterdrücken). Wget sendet GET-Anfragen und leitet standardmäßig automatisch auf Weiterleitungen um.
Wenn du dich mit Kommandozeilen-Tools nicht auskennst, gibt es auch viele browserbasierte Optionen. Zum Beispiel:
- Redirect Check, (Website) Wenn du eine URL angibst, verfolgt Redirect Check den Umleitungspfad und meldet die Antwort-Header, die der Server für jede Anfrage zurückgibt.
- Die Netzwerkinspektionstools von Google Chrome oder Mozilla Firefox (Browser-Tools). Mit diesen Tools kannst du die Anfragen deines Webbrowsers aufzeichnen und ihre Antwort-Header untersuchen.
2. Kenne den Unterschied zwischen 301 und 302.
Der HTTP-Antwortcode, der bei einer Weiterleitung zurückgegeben wird, kann einen wertvollen Einblick in den Zweck der Weiterleitung geben und wie Web-Proxys und Browser entscheiden, wie sie zukünftige Anfragen an die weitergeleitete URL behandeln sollen.
- 301 „Dauerhaft verschoben“: Diese Art der Weiterleitung soll andeuten, dass die angefragte Ressource dauerhaft an einen neuen Ort umgezogen ist und kann von Proxy-Servern und Webbrowsern zwischengespeichert werden. Wenn du versuchst, diese Art von Weiterleitung zu beheben, überprüfe die Antwort-Header „Cache-Control“ und „X-Cache“, die vom Server gesendet werden, um festzustellen, ob die Weiterleitung aus einem Cache (z. B. Varnish auf deinen Acquia Cloud Load Balancern) bereitgestellt wird, der möglicherweise gelöscht werden muss, bevor das Problem behoben ist.
- 302 „Gefunden“ oder „Vorübergehend verschoben“: Diese Weiterleitungsart bedeutet eine temporäre oder „einmalige“ Weiterleitung, die nicht von Web-Proxys oder Browsern zwischengespeichert werden sollte. Dies ist der Standard-Statuscode, den das Rewrite-Modul von Apache für Weiterleitungen zurückgibt, die über RewriteRules in einer .htaccess- oder vhost-Konfigurationsdatei definiert wurden. Außerdem ist dies der Standard-Statuscode für die Funktion drupal_goto, die von Drupal Core (Version 7 und früher) verwendet wird, um eingehende Anfragen umzuleiten.
3. Achte auf den Antwort-Header „Location“.
Der Response-Header „Location“, den der Server bei einer Weiterleitung zurückgibt, wird verwendet, um eine nachfolgende HTTP-Anfrage an den aktualisierten Standort der Ressource zu stellen. Er kann bei der Fehlersuche bei problematischen Weiterleitungen nützlich sein, insbesondere bei Weiterleitungsschleifen, bei denen die in diesem Header angegebenen Werte den anfragenden Client letztendlich zu der ursprünglich angefragten URL zurückführen und so eine Endlosschleife von Webanfragen verursachen, die eine erfolgreiche Auflösung von Webseiten verhindert. Wenn du auf den Wert dieser Umleitung achtest, kannst du den Zweck der Umleitung erkennen. Hier sind einige Beispiele für gängige Umleitungspraktiken, die durch den „Location“-Header ausgedrückt werden:
- Umleitung zwischen der HTTP- und HTTPS-Version einer Seite
- Hinzufügen oder Entfernen des hinteren Schrägstrichs (/) am Ende einer Anfrage-URL.
- Umleitung zwischen „www.“ und „reinen“ Domains (z.B.: Umleitung von „example.com“ zu „www.example.com“ und umgekehrt).
- Umleitung auf den aktualisierten URL-Alias einer Drupal-Seite, nachdem eine Inhaltsänderung gespeichert wurde.
Wenn du darauf achtest, wie sich dieser Header ändert, wenn eine Anfrage von einer URL auf eine andere umgestellt wird, und diese Informationen nutzt, um herauszufinden, was die Umleitung bezweckt, kannst du den Teil des Codes oder der Konfiguration deiner Website eingrenzen, der für die Umleitung verantwortlich ist.
4. Überprüfe die Antwort-Header Server, Via, X-Generator und X-Drupal-Cache.
Die Antwort-Header Server, Via, X-Generator und X-Drupal-Cache können Aufschluss darüber geben, welcher Teil deiner Webanwendung für die Weiterleitung verantwortlich ist. Zum Beispiel auf einer Acquia Cloud Drupal Website:
- Das Vorhandensein des „X-Drupal-Cache“-Headers (mit einem beliebigen Wert) oder des „X-Generator“-Headers (mit einem Wert, der das Wort „Drupal“ enthält) deutet darauf hin, dass die Antwort vom Drupal-CMS bereitgestellt wird und wahrscheinlich das Produkt eines beigetragenen oder benutzerdefinierten Moduls in der Codebasis deiner Website ist.
- Wenn der „Server“-Header „Nginx“ enthält, aber keiner der oben erwähnten Drupal-bezogenen Header vorhanden ist, wird die Weiterleitung wahrscheinlich durch eine Rewrite-Regel in der .htaccess-Datei deiner Website ausgelöst, vor allem, wenn der „Location“-Header auf eine der in Abschnitt 3 erwähnten üblichen Weiterleitungspraktiken hinweist.
- Wenn Varnish auf den Load Balancern deiner Website an der Zustellung der Antwort beteiligt ist, fügt die Software einen „Via“-Antwort-Header hinzu, dessen Wert „1.1 varnish“ enthält. Das Vorhandensein dieses Headers deutet darauf hin, dass eine Logik in der Varnish-Konfigurationsdatei (VCL) deiner Website für die Weiterleitung verantwortlich ist, insbesondere wenn du eine angepasste VCL auf deinen Acquia Cloud Load Balancern verwendest.
- In einigen Fällen kann der „Server“-Header auf die Beteiligung eines Content Delivery Network (CDN) wie CloudFlare oder Akamai hinweisen. Ein „Server“-Header, der einen Wert wie „AkamaiGhost“ oder „cloudflare-nginx“ enthält, kann – vor allem wenn die anderen oben genannten Header fehlen – darauf hinweisen, dass ein Teil der Funktionalität deines CDNs für die Weiterleitung verantwortlich ist.
5. Überlege, ob diese beliebten Drupal-Module beteiligt sind.
Die folgenden Drupal-Module werden auf vielen Websites verwendet, um einige gängige Weiterleitungsfunktionen zu implementieren. Wenn diese Module auf deiner Website aktiviert sind, insbesondere wenn die oben genannten Header „X-Generator“ oder „X-Drupal-Cache“ in der Weiterleitung, die du beheben willst, vorhanden sind, solltest du überprüfen, ob sie richtig konfiguriert sind:
- Redirect bietet eine administrative Schnittstelle, mit der Website-Betreiber eine eingehende Anfrage an eine URL ihrer Wahl mit einem Antwortcode ihrer Wahl umleiten können. Dieses Modul stellt auch eine API zur Verfügung, die von anderen Modulen genutzt werden kann, um ihre eigenen Umleitungsfunktionen zu implementieren. Wenn du einen „X-Redirect-ID“-Antwort-Header bei der Umleitung siehst, die du gerade behebst, ist das Redirect-Modul dafür verantwortlich und du kannst den Wert dieses Headers verwenden, um die Umleitung in der Verwaltungsoberfläche des Moduls zu suchen und zu bearbeiten.
- Global Redirect bietet auch einige allgemeine Umleitungsfunktionen, wie das „Entschlacken“ von URLs und die Umleitung von Systempfaden zu Pfadaliasen.
- Secure Pages führt eine 302-Umleitung zwischen den HTTP- und HTTPS-Versionen der Drupal-Seiten auf deiner Website durch. In manchen Fällen kann die Verwendung dieses Moduls in Verbindung mit .htaccess-Regeln, die alle eingehenden Anfragen auf HTTPS umleiten sollen, eine Umleitungsschleife verursachen.
- Die Internationalization (i18n) Suite enthält ein Modul namens Translation Redirect, mit dem Anfragen zu den lokalisierten oder übersetzten Versionen der Inhalte umgeleitet werden können
Hey, ich bin Keith …
… ich begleite dich ab heute auf meinem neuen kleinen Berliner Blog in die Welt des Webdesigns & des visuellen Marketings.
Ich selbst habe Wirtschaftsinformatik in Leipzig studiert und mir alles Wichtige in Sachen Webdesign parallel zum Studium beigebracht.
Mittlerweile arbeite ich selbstständig und betreue in Berlin viele mittelständische Kunden.
Hier werden auch alle möglichen Beiträge rund um digitales Marketing und die Start-up-Szene in Deutschland erscheinen.
Falls dich meine Welt fasziniert und du mehr über CSS, JS & HTML5 lernen möchtest, abonniere doch gerne meinen Newsletter!
Best wishes from Berlin – dein Keith Beerman! <3