{"id":34730,"date":"2020-05-12T02:45:54","date_gmt":"2020-05-12T09:45:54","guid":{"rendered":"https:\/\/kinsta.com\/?post_type=knowledgebase&p=71506"},"modified":"2025-10-01T20:22:01","modified_gmt":"2025-10-01T19:22:01","slug":"307-redirect","status":"publish","type":"post","link":"https:\/\/kinsta.com\/de\/blog\/307-redirect\/","title":{"rendered":"Den HTTP 307 Temporary Redirect Status Code wirklich verstehen"},"content":{"rendered":"

Das HTTP-Protokoll definiert \u00fcber 40 Server-Statuscodes<\/a>, von denen 9 explizit f\u00fcr URL-Umleitungen vorgesehen sind. Jeder Redirect-Statuscode beginnt mit der Ziffer 3 (HTTP 3xx) und hat seine eigene Methode zur Behandlung der Umleitungen. W\u00e4hrend einige von ihnen \u00e4hnlich sind, gehen sie alle unterschiedlich mit den Umleitungen um.<\/p>\n

Zu verstehen, wie jeder HTTP-Redirect-Statuscode funktioniert, ist entscheidend f\u00fcr die Diagnose oder Behebung von Webseiten-Konfigurationsfehlern.<\/p>\n

In diesem Leitfaden gehen wir ausf\u00fchrlich auf die Statuscodes HTTP 307 Temporary Redirect <\/strong>und 307 Internal Redirect<\/strong> ein, einschlie\u00dflich ihrer Bedeutung und wie sie sich von anderen 3xx-Redirect-Statuscodes unterscheiden.<\/p>\n

Fangen wir also an!<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Wie funktioniert die HTTP 3xx-Umleitung?<\/h2>\n

Bevor wir uns in die 307 Temporary Redirect- und 307 Internal Redirect-Antworten vertiefen, wollen wir verstehen, wie die HTTP-Umleitung funktioniert.<\/p>\n

HTTP-Statuscodes<\/a> 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<\/strong> implizieren eine Umleitung. Sie befehlen dem Browser, auf eine neue URL umzuleiten, die im Location<\/strong>-Header der Antwort des Servers definiert ist.<\/p>\n

\"HTTP
HTTP 3xx-Umleitungen bei der Arbeit<\/figcaption><\/figure>\n

Wenn dein Browser auf eine Umleitungsanforderung vom Server st\u00f6\u00dft, ben\u00f6tigt er ein Verst\u00e4ndnis f\u00fcr die Art dieser Anforderung. Die verschiedenen HTTP 3xx-Umleitungsstatuscodes behandeln diese Anfragen. Wenn wir sie alle kennen, k\u00f6nnen wir 307 Temporary Redirect und 307 Internal Redirect besser verstehen.<\/p>\n

Die verschiedenen HTTP 3xx-Umleitungen<\/h2>\n

Es gibt verschiedene Arten von HTTP 3xx Redirect-Statuscodes<\/a>. Die urspr\u00fcngliche HTTP-Spezifikation enthielt nicht 307 Temporary Redirect und 308 Permanent Redirect, da diese Rollen durch 301 Moved Permanently und 302 Found besetzt werden sollten.<\/p>\n

Die meisten Clients \u00e4nderten jedoch die HTTP-Anforderungsmethode<\/a> f\u00fcr 301 und 302 Redirect Responses von POST auf GET, obwohl die HTTP-Spezifikation dies den Clients nicht erlaubte. Dieses Verhalten machte die Einf\u00fchrung der strengeren Statuscodes 307 Temporary Redirect<\/strong> und 308 Permanent Redirect<\/strong> in der HTTP\/1.1-Aktualisierung<\/a> erforderlich.<\/p>\n

Die 307 Internal Redirect<\/strong> Antwort ist eine Variante des 307 Temporary Redirect <\/strong>Statuscodes. Sie ist nicht durch den HTTP-Standard definiert und ist nur eine lokale Browser-Implementierung. Wir werden das sp\u00e4ter ausf\u00fchrlicher besprechen.<\/p>\n

W\u00e4hrend Redirect-Statuscodes wie 301 und 308 standardm\u00e4\u00dfig 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<\/strong> oder Expires<\/strong>-Response-Header-Feld hinzuf\u00fcgst.<\/p>\n

\"HTTP
HTTP Weiterleitungen sind nicht so komplex<\/figcaption><\/figure>\n

Verwendung von 302 vs. 303 vs. 307 f\u00fcr tempor\u00e4re Umleitungen<\/h2>\n

Wie aus der obigen Tabelle ersichtlich, hast du f\u00fcr tempor\u00e4re Weiterleitungen drei M\u00f6glichkeiten: 302, 303 oder 307. Die meisten Clients behandeln jedoch 302 Statuscode als 303 Antwort und \u00e4ndern die HTTP-Anforderungsmethode in GET. Dies ist vom Sicherheitsstandpunkt<\/a> aus nicht ideal.<\/p>\n

„RFC 1945 und RFC 2068 legen fest, dass der Client die Methode bei der umgeleiteten Anfrage nicht \u00e4ndern darf. Die meisten vorhandenen User-Agent-Implementierungen behandeln 302 jedoch so, als w\u00e4re es eine 303-Antwort, wobei unabh\u00e4ngig von der urspr\u00fcnglichen Anfragemethode ein GET auf den Feldwert Location durchgef\u00fchrt wird. Die Statuscodes 303 und 307 wurden f\u00fcr Server hinzugef\u00fcgt, die eindeutig klarstellen wollen, welche Art von Reaktion vom Client erwartet wird“.<\/em>
\n– HTTP\/1.1. Definitionen der Statuscodes, W3.org<\/a><\/p><\/blockquote>\n

Verwende daher f\u00fcr tempor\u00e4re Umleitungen, bei denen du die HTTP-Anforderungsmethode beibehalten musst, die strengere 307 Temporary Redirect<\/strong> Antwort.<\/p>\n

Leite z.B. \/register-form.html nach signup-form.html um, oder von \/login.php nach \/signin.php.<\/p>\n

F\u00fcr F\u00e4lle, in denen du die Umleitungsmethode auf GET \u00e4ndern musst, verwende stattdessen die 303 See Other<\/strong> Antwort.<\/p>\n

Zum Beispiel die Umleitung einer POST-Anforderung von der Seite \/register.php zum Laden einer Seite \/success.html \u00fcber eine GET-Anforderung.<\/p>\n

Sofern deine Zielgruppe keine Legacy-Clients verwendet, solltest du die 302 Found<\/strong> redirect-Antwort vermeiden.<\/p>\n

307 Interne Umleitung f\u00fcr reine HTTPS-Webseiten verstehen<\/h2>\n

Wenn du eine reine HTTPS<\/a>-Webseite hast (was du tun solltest<\/a>), wird dein Browser, wenn du versuchst, sie unsicher \u00fcber die regul\u00e4re http:\/\/ zu besuchen, automatisch zu ihrer sicheren https:\/\/ Version umgeleitet. Typischerweise geschieht dies mit einer 301 Moved Permanent Redirect-Antwort vom Server.<\/p>\n

Wenn du zum Beispiel http:\/\/citibank.com<\/a> besuchst und DevTools<\/strong> in Chrome l\u00e4dst und die Registerkarte Netzwerk<\/strong> ausw\u00e4hlst, kannst du alle zwischen dem Browser und dem Server get\u00e4tigten Anfragen sehen.<\/p>\n

Die erste Antwort ist 301 Moved Permanently,<\/strong> die den Browser auf die HTTPS-Version der Webseite umleitet.<\/p>\n

\"301
301 Antwort wird zur HTTPS-Version umgeleitet<\/figcaption><\/figure>\n

Wenn wir tiefer in die Header<\/strong>-Felder der ersten Anfrage graben, k\u00f6nnen wir sehen, dass der Location<\/strong>-Response-Header definiert, was die sichere URL f\u00fcr die Umleitung ist.<\/p>\n

\"Der
Der Location-Response-Header definiert die Umleitungs-URL<\/figcaption><\/figure>\n

Das Problem bei diesem Ansatz besteht darin, dass b\u00f6swillige Akteure die Netzwerkverbindung kapern k\u00f6nnen, um den Browser auf eine benutzerdefinierte URL umzuleiten. Man-in-the-Middle (MITM)-Angriffe<\/a> wie dieser sind recht h\u00e4ufig. Eine beliebte Fernsehserie hat sie sogar in einer ihrer Episoden gef\u00e4lscht<\/a>.<\/p>\n

Au\u00dferdem kann eine b\u00f6swillige Partei einen MITM-Angriff starten, ohne die in der Adressleiste des Browsers angezeigte URL zu \u00e4ndern. Beispielsweise kann dem Benutzer eine Phishing-Seite angeboten werden, die genau wie die urspr\u00fcngliche Webseite aussieht.<\/p>\n

Und da alles gleich aussieht, einschlie\u00dflich der URL in der Adressleiste, werden die meisten Benutzer gerne ihre Anmeldedaten eingeben. Du kannst dir vorstellen, warum das schlecht sein kann.<\/p>\n

\"301
301 Weiterleitungen an HTTPS sind nicht sicher<\/figcaption><\/figure>\n

Sichere Umleitungen mit 307 Internal Redirect<\/h3>\n

Lasst uns dasselbe Beispiel mit Kinsta versuchen. Der Besuch von https:\/\/kinsta.com<\/a> f\u00fchrt zu Netzwerkanfragen, wie im Screenshot unten gezeigt.<\/p>\n

\"Ein
Ein Beispiel f\u00fcr 307 Internal Redirect<\/figcaption><\/figure>\n

Die erste Anfrage der Webseite ist wie das vorherige Beispiel, aber dieses Mal f\u00fchrt sie zu einer 307 Internal Redirect<\/strong>-Antwort. Wenn man darauf klickt, erhalten wir weitere Einzelheiten zu dieser Antwort.<\/p>\n

Hinweis<\/strong>: Wenn du versuchst, die Webseite direkt mit https:\/\/<\/strong> zu besuchen, wirst du diesen Header nicht sehen, da der Browser keine Umleitung ben\u00f6tigt.<\/p>\n

\"Response-Header
Response-Header der Antwort 307 Internal Redirect<\/figcaption><\/figure>\n

Beachte den Header Non-Authoritative-Reason: HSTS response. Hierbei handelt es sich um den HTTP-Antwortheader Strict Transport Security (HSTS)<\/a>, auch bekannt als der Strict-Transport-Security-Antwortheader.<\/p>\n

Was ist HSTS (Strikte Transportsicherheit)?<\/h3>\n

Die IETF ratifizierte HTTP Strict Transport Security (HSTS) im Jahr 2012<\/a>, um Browser zur Verwendung sicherer Verbindungen zu zwingen, wenn eine Webseite strikt \u00fcber HTTPS l\u00e4uft.<\/p>\n

Das ist so, als w\u00fcrden Chrome oder Firefox sagen: „Ich werde nicht einmal versuchen, diese Webseite oder eine ihrer Ressourcen \u00fcber das unsichere HTTP-Protokoll anzufordern. Stattdessen werde ich es auf HTTPS \u00e4ndern und es erneut versuchen.<\/p>\n

Du kannst Kinsta’s Anleitung folgen, wie du HSTS auf deiner WordPress Webseite<\/a> zum Laufen bringen kannst.<\/p>\n

\"Bessere
Bessere Sicherheit mit dem 307 Internal Redirect<\/figcaption><\/figure>\n

Wenn wir uns eingehender mit dem Response-Header der zweiten Anfrage befassen, werden wir ein besseres Verst\u00e4ndnis erhalten.<\/p>\n

\"Verifizierung
Verifizierung des HSTS-Antwort-Headers<\/figcaption><\/figure>\n

Hier siehst du die strict-transport-security: max age=31536000 response header.<\/p>\n

Das Max-Age<\/strong>-Attribut des Strict-Transport-Security<\/strong>-Antwort-Headers definiert, wie lange der Browser diesem Muster folgen soll. Im obigen Beispiel ist dieser Wert auf 3153600 Sekunden (oder 1 Jahr) festgelegt.<\/p>\n

Sobald eine Webseite diesen Response-Header zur\u00fcckgibt, wird der Browser nicht einmal versuchen, eine normale HTTP-Anfrage zu stellen. Stattdessen f\u00fchrt er eine 307 Internal Redirect<\/strong> auf HTTPS durch und versucht es erneut.<\/p>\n

Bei jeder Wiederholung dieses Vorgangs werden die Response-Header zur\u00fcckgesetzt. Daher wird der Browser f\u00fcr eine unbestimmte Zeit keine unsichere Anfrage stellen k\u00f6nnen.<\/p>\n

Wenn du deine Webseite bei Kinsta hostest, kannst du ein Support-Ticket<\/a> erstellen, damit der HSTS-Header zu deiner WordPress-Seite hinzugef\u00fcgt wird. Da das Hinzuf\u00fcgen des HSTS-Headers Leistungsvorteile gew\u00e4hrt, wird empfohlen, dass du HSTS f\u00fcr deine Webseite aktivierst.<\/p>\n

Was ist eine HSTS Preload Liste?<\/h3>\n

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.<\/p>\n

Au\u00dferdem kann der HSTS-Antwort-Header nur \u00fcber HTTPS gesendet werden, so dass die erste unsichere Anfrage nicht einmal zur\u00fcckgeschickt werden kann.<\/p>\n

Um dieses Problem zu beheben, unterst\u00fctzt 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\u00e4ndig umgangen wird.<\/p>\n

Wenn du deine Webseite zur HSTS Preload Liste des Browsers hinzuf\u00fcgst, 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<\/strong>, um deine Webseite auf sein sicheres https:\/\/ Schema umzuleiten, bevor er irgendetwas anderes anfordert.<\/p>\n

Du solltest beachten, dass im Gegensatz zu 307 Temporary Redirect<\/strong> die 307 Internal Redirect<\/strong>-Antwort ein „gef\u00e4lschter 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).<\/p>\n

Das Hinzuf\u00fcgen einer Webseite zu einer HSTS-Preload Liste hat viele Vorteile:<\/p>\n

    \n
  1. Der Webserver sieht nie unsichere HTTP-Anfragen. Dies reduziert die Serverlast und macht die Webseite sicherer.<\/li>\n
  2. Der Browser k\u00fcmmert sich um die Umleitung von HTTP zu HTTPS<\/a>, wodurch die Webseite schneller und sicherer wird.<\/li>\n<\/ol>\n

    HSTS Preload Liste Anforderungen<\/h3>\n

    Wenn du deine Webseite zur HSTS Preload Liste eines Browsers hinzuf\u00fcgen m\u00f6chtest, muss sie die folgenden Bedingungen abhaken:<\/p>\n