Das HTTP-Protokoll definiert über 40 Server-Statuscodes, von denen 9 explizit für URL-Umleitungen vorgesehen sind. Jeder Redirect-Statuscode beginnt mit der Ziffer 3 (HTTP 3xx) und hat seine eigene Methode zur Behandlung der Umleitungen. Während einige von ihnen ähnlich sind, gehen sie alle unterschiedlich mit den Umleitungen um.
Zu verstehen, wie jeder HTTP-Redirect-Statuscode funktioniert, ist entscheidend für die Diagnose oder Behebung von Webseiten-Konfigurationsfehlern.
In diesem Leitfaden gehen wir ausführlich auf die Statuscodes HTTP 307 Temporary Redirect und 307 Internal Redirect ein, einschließlich ihrer Bedeutung und wie sie sich von anderen 3xx-Redirect-Statuscodes unterscheiden.
Fangen wir also an!
Wie funktioniert die HTTP 3xx-Umleitung?
Bevor wir uns in die 307 Temporary Redirect- und 307 Internal Redirect-Antworten vertiefen, wollen wir verstehen, wie die HTTP-Umleitung funktioniert.
HTTP-Statuscodes sind Antworten vom Server an den Browser. Jeder Statuscode ist eine dreistellige Zahl, und die erste Ziffer definiert, um welche Art von Antwort es sich handelt. HTTP 3xx-Statuscodes implizieren eine Umleitung. Sie befehlen dem Browser, auf eine neue URL umzuleiten, die im Location-Header der Antwort des Servers definiert ist.
Wenn dein Browser auf eine Umleitungsanforderung vom Server stößt, benötigt er ein Verständnis für die Art dieser Anforderung. Die verschiedenen HTTP 3xx-Umleitungsstatuscodes behandeln diese Anfragen. Wenn wir sie alle kennen, können wir 307 Temporary Redirect und 307 Internal Redirect besser verstehen.
Die verschiedenen HTTP 3xx-Umleitungen
Es gibt verschiedene Arten von HTTP 3xx Redirect-Statuscodes. Die ursprüngliche HTTP-Spezifikation enthielt nicht 307 Temporary Redirect und 308 Permanent Redirect, da diese Rollen durch 301 Moved Permanently und 302 Found besetzt werden sollten.
Die meisten Clients änderten jedoch die HTTP-Anforderungsmethode für 301 und 302 Redirect Responses von POST auf GET, obwohl die HTTP-Spezifikation dies den Clients nicht erlaubte. Dieses Verhalten machte die Einführung der strengeren Statuscodes 307 Temporary Redirect und 308 Permanent Redirect in der HTTP/1.1-Aktualisierung erforderlich.
Die 307 Internal Redirect Antwort ist eine Variante des 307 Temporary Redirect Statuscodes. Sie ist nicht durch den HTTP-Standard definiert und ist nur eine lokale Browser-Implementierung. Wir werden das später ausführlicher besprechen.
Während Redirect-Statuscodes wie 301 und 308 standardmäßig zwischengespeichert werden, werden andere wie 302 und 307 nicht zwischengespeichert. Du kannst jedoch alle Redirect-Antworten in den Cache aufnehmen (oder auch nicht), indem du ein Cache-Control oder Expires-Response-Header-Feld hinzufügst.
Verwendung von 302 vs. 303 vs. 307 für temporäre Umleitungen
Wie aus der obigen Tabelle ersichtlich, hast du für temporäre Weiterleitungen drei Möglichkeiten: 302, 303 oder 307. Die meisten Clients behandeln jedoch 302 Statuscode als 303 Antwort und ändern die HTTP-Anforderungsmethode in GET. Dies ist vom Sicherheitsstandpunkt aus nicht ideal.
„RFC 1945 und RFC 2068 legen fest, dass der Client die Methode bei der umgeleiteten Anfrage nicht ändern darf. Die meisten vorhandenen User-Agent-Implementierungen behandeln 302 jedoch so, als wäre es eine 303-Antwort, wobei unabhängig von der ursprünglichen Anfragemethode ein GET auf den Feldwert Location durchgeführt wird. Die Statuscodes 303 und 307 wurden für Server hinzugefügt, die eindeutig klarstellen wollen, welche Art von Reaktion vom Client erwartet wird“.
– HTTP/1.1. Definitionen der Statuscodes, W3.org
Verwende daher für temporäre Umleitungen, bei denen du die HTTP-Anforderungsmethode beibehalten musst, die strengere 307 Temporary Redirect Antwort.
Leite z.B. /register-form.html nach signup-form.html um, oder von /login.php nach /signin.php.
Für Fälle, in denen du die Umleitungsmethode auf GET ändern musst, verwende stattdessen die 303 See Other Antwort.
Zum Beispiel die Umleitung einer POST-Anforderung von der Seite /register.php zum Laden einer Seite /success.html über eine GET-Anforderung.
Sofern deine Zielgruppe keine Legacy-Clients verwendet, solltest du die 302 Found redirect-Antwort vermeiden.
307 Interne Umleitung für reine HTTPS-Webseiten verstehen
Wenn du eine reine HTTPS-Webseite hast (was du tun solltest), wird dein Browser, wenn du versuchst, sie unsicher über die reguläre http:// zu besuchen, automatisch zu ihrer sicheren https:// Version umgeleitet. Typischerweise geschieht dies mit einer 301 Moved Permanent Redirect-Antwort vom Server.
Wenn du zum Beispiel http://citibank.com besuchst und DevTools in Chrome lädst und die Registerkarte Netzwerk auswählst, kannst du alle zwischen dem Browser und dem Server getätigten Anfragen sehen.
Die erste Antwort ist 301 Moved Permanently, die den Browser auf die HTTPS-Version der Webseite umleitet.
Wenn wir tiefer in die Header-Felder der ersten Anfrage graben, können wir sehen, dass der Location-Response-Header definiert, was die sichere URL für die Umleitung ist.
Das Problem bei diesem Ansatz besteht darin, dass böswillige Akteure die Netzwerkverbindung kapern können, um den Browser auf eine benutzerdefinierte URL umzuleiten. Man-in-the-Middle (MITM)-Angriffe wie dieser sind recht häufig. Eine beliebte Fernsehserie hat sie sogar in einer ihrer Episoden gefälscht.
Außerdem kann eine böswillige Partei einen MITM-Angriff starten, ohne die in der Adressleiste des Browsers angezeigte URL zu ändern. Beispielsweise kann dem Benutzer eine Phishing-Seite angeboten werden, die genau wie die ursprüngliche Webseite aussieht.
Und da alles gleich aussieht, einschließlich der URL in der Adressleiste, werden die meisten Benutzer gerne ihre Anmeldedaten eingeben. Du kannst dir vorstellen, warum das schlecht sein kann.
Sichere Umleitungen mit 307 Internal Redirect
Lasst uns dasselbe Beispiel mit Kinsta versuchen. Der Besuch von http://kinsta.com führt zu Netzwerkanfragen, wie im Screenshot unten gezeigt.
Die erste Anfrage der Webseite ist wie das vorherige Beispiel, aber dieses Mal führt sie zu einer 307 Internal Redirect-Antwort. Wenn man darauf klickt, erhalten wir weitere Einzelheiten zu dieser Antwort.
Hinweis: Wenn du versuchst, die Webseite direkt mit https:// zu besuchen, wirst du diesen Header nicht sehen, da der Browser keine Umleitung benötigt.
Beachte den Header Non-Authoritative-Reason: HSTS response. Hierbei handelt es sich um den HTTP-Antwortheader Strict Transport Security (HSTS), auch bekannt als der Strict-Transport-Security-Antwortheader.
Was ist HSTS (Strikte Transportsicherheit)?
Die IETF ratifizierte HTTP Strict Transport Security (HSTS) im Jahr 2012, um Browser zur Verwendung sicherer Verbindungen zu zwingen, wenn eine Webseite strikt über HTTPS läuft.
Das ist so, als würden Chrome oder Firefox sagen: „Ich werde nicht einmal versuchen, diese Webseite oder eine ihrer Ressourcen über das unsichere HTTP-Protokoll anzufordern. Stattdessen werde ich es auf HTTPS ändern und es erneut versuchen.
Du kannst Kinsta’s Anleitung folgen, wie du HSTS auf deiner WordPress Webseite zum Laufen bringen kannst.
Wenn wir uns eingehender mit dem Response-Header der zweiten Anfrage befassen, werden wir ein besseres Verständnis erhalten.
Hier siehst du die strict-transport-security: max age=31536000 response header.
Das Max-Age-Attribut des Strict-Transport-Security-Antwort-Headers definiert, wie lange der Browser diesem Muster folgen soll. Im obigen Beispiel ist dieser Wert auf 3153600 Sekunden (oder 1 Jahr) festgelegt.
Sobald eine Webseite diesen Response-Header zurückgibt, wird der Browser nicht einmal versuchen, eine normale HTTP-Anfrage zu stellen. Stattdessen führt er eine 307 Internal Redirect auf HTTPS durch und versucht es erneut.
Bei jeder Wiederholung dieses Vorgangs werden die Response-Header zurückgesetzt. Daher wird der Browser für eine unbestimmte Zeit keine unsichere Anfrage stellen können.
Wenn du deine Webseite bei Kinsta hostest, kannst du ein Support-Ticket erstellen, damit der HSTS-Header zu deiner WordPress-Seite hinzugefügt wird. Da das Hinzufügen des HSTS-Headers Leistungsvorteile gewährt, wird empfohlen, dass du HSTS für deine Webseite aktivierst.
Was ist eine HSTS Preload Liste?
Auch beim HSTS gibt es ein eklatantes Sicherheitsproblem. Die allererste HTTP-Anforderung, die du mit dem Browser sendest, ist unsicher, wodurch sich das Problem wiederholt, das wir zuvor bei Citibank beobachtet haben.
Außerdem kann der HSTS-Antwort-Header nur über HTTPS gesendet werden, so dass die erste unsichere Anfrage nicht einmal zurückgeschickt werden kann.
Um dieses Problem zu beheben, unterstützt HSTS ein Vorladeattribut in seinem Response-Header. Die Idee besteht darin, eine Liste von Webseiten zu haben, die das Vorladen von HSTS im Browser selbst erzwingen, wodurch dieses Sicherheitsproblem vollständig umgangen wird.
Wenn du deine Webseite zur HSTS Preload Liste des Browsers hinzufügst, wird dieser wissen, dass deine Webseite strenge HSTS-Richtlinien durchsetzt, selbst wenn sie deine Webseite zum ersten Mal besucht. Der Browser verwendet dann die Antwort 307 Internal Redirect, um deine Webseite auf sein sicheres https:// Schema umzuleiten, bevor er irgendetwas anderes anfordert.
Du solltest beachten, dass im Gegensatz zu 307 Temporary Redirect die 307 Internal Redirect-Antwort ein „gefälschter Header“ ist, der vom Browser selbst gesetzt wird. Sie kommt nicht vom Server, dem Web-Host (z.B. Kinsta) oder dem CMS (z.B. WordPress).
Das Hinzufügen einer Webseite zu einer HSTS-Preload Liste hat viele Vorteile:
- Der Webserver sieht nie unsichere HTTP-Anfragen. Dies reduziert die Serverlast und macht die Webseite sicherer.
- Der Browser kümmert sich um die Umleitung von HTTP zu HTTPS, wodurch die Webseite schneller und sicherer wird.
HSTS Preload Liste Anforderungen
Wenn du deine Webseite zur HSTS Preload Liste eines Browsers hinzufügen möchtest, muss sie die folgenden Bedingungen abhaken:
- Ein gültiges SSL/TLS-Zertifikat muss für deine Domain installiert sein.
- Erzwinge striktes HTTPS, indem du den gesamten HTTP-Verkehr zu HTTPS umleitest.
- Alle Subdomains sollten über HTTPS bedient werden, insbesondere die www-Subdomain, falls ein DNS-Eintrag für diese Subdomain existiert.
- Deine Basisdomain sollte einen HSTS-Header mit den folgenden Attributen enthalten:
- Das Max-Age-Attribut muss für mindestens 31536000 Sekunden (1 Jahr) gesetzt sein.
- Die includeSubdomains und Vorladeanweisungen müssen angegeben werden.
- Wenn du eine zusätzliche Umleitung anbietest, muss diese den HSTS-Header enthalten, nicht die Seite, auf die umgeleitet wird.
Hinzufügen deiner Webseite zur HSTS-Preload Liste
Es gibt zwei Möglichkeiten, deine Webseite zur HSTS-Preload Liste hinzuzufügen.
- Indem du deine Webseite in ein Verzeichnis der HSTS-Preload-Liste einträgst. Zum Beispiel wird die hstspreload.org-Masterliste vom Open-Source-Projekt Chromium gepflegt und von den meisten gängigen Browsern (Firefox, Chrome, Safari, IE 11 und Edge) verwendet.
- Durch Hinzufügen des folgenden Header-Feldes zu deiner Webseite:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Bei der zweiten Methode wird der allererste Besuch deiner Webseite durch den Browser nicht völlig sicher sein. Spätere Besuche werden jedoch vollkommen sicher sein.
Du kannst ein kostenloses Online-Tool wie Security Headers benutzen, um zu überprüfen, ob deine Webseite HSTS durchsetzt oder nicht. Wenn du dir Sorgen um die Browser-Unterstützung für HSTS machst, kannst du sicher sein, dass HSTS von fast allen heute verwendeten Browsern unterstützt wird.
HTTP 307 Umleitungen und SEO
Da eine 307 Temporary Redirect-Antwort zeigt, dass die Ressource vorübergehend auf eine neue URL umgeleitet wurde, aktualisieren Suchmaschinen ihren Index nicht, um diese neue URL aufzunehmen. Der ‚Link-Juice‘ von der ursprünglichen URL wird nicht an die neue URL weitergegeben.
Dies steht im Gegensatz zu 301 Moved Permanent Redirects, bei denen Suchmaschinen ihren Index aktualisieren, um die neue URL aufzunehmen, und den „Link-Juice“ von der ursprünglichen URL an die neue URL weitergeben.
Bei einer 307 Internal Redirect-Antwort geschieht alles auf Browser-Ebene. Daher sollte sie keine direkten Auswirkungen auf die SEO deiner Webseite haben. Durch das Hinzufügen deiner Webseite zu einer HSTS-Preload Liste wird sie jedoch schneller geladen und sicherer, was beides dazu beitragen kann, dass sie in den Suchergebnissen höher eingestuft wird.
Achte darauf, dass du Nutzer und Bots nicht versehentlich in eine unendliche Umleitungsschleife umleitest, was den Fehler „too many redirects“ verursacht.
Zusammenfassung
Die URL-Umleitung ermöglicht es dir, einer Webseite mehr als eine URL-Adresse zuzuweisen. Die URL-Umleitungen werden am besten auf Serverebene mit HTTP 3xx-Redirect-Statuscode-Antworten gehandhabt. Wenn deine Webseite wegen Wartungsarbeiten oder aus anderen Gründen nicht verfügbar ist, kannst du sie mit einer 307 Temporary Redirect-Antwort vorübergehend auf eine andere URL umleiten.
Abgesehen davon führt jede Umleitung zu einer Verzögerung bei der Ladezeit deiner Seite. Verwende daher Umleitungen mit Bedacht und behalte dabei stets die Erfahrung des Endbenutzers im Auge.
