Statuscode 307 Temporary Redirect: Die Präzise Weiterleitung

INEZA Felin-Michel

INEZA Felin-Michel

24 September 2025

Statuscode 307 Temporary Redirect: Die Präzise Weiterleitung

Sie schließen einen großen Online-Einkauf ab. Sie geben Ihre Kreditkartendaten ein, klicken auf die Schaltfläche "Jetzt bezahlen", und für einen kurzen Moment sendet Ihr Browser eine POST-Anfrage mit all Ihren sensiblen Daten. Plötzlich muss der Server Sie auf eine 3D-Secure-Authentifizierungsseite weiterleiten. Was passiert mit dieser ursprünglichen POST-Anfrage mit Ihren Zahlungsinformationen? Geht sie verloren? Wird sie falsch gesendet?

Dieses kritische Szenario ist der Punkt, an dem die subtilen Unterschiede zwischen HTTP-Weiterleitungscodes massiv wichtig werden. Es ist die spezifische Aufgabe eines der präzisesten und wertvollsten Statuscodes: 307 Temporary Redirect.

Während sein Verwandter 302 Found eine bekannte "temporäre Weiterleitung" ist, ist 307 sein strengerer, zuverlässigerer Bruder. Er wurde geschaffen, um eine entscheidende Unklarheit in der ursprünglichen HTTP-Spezifikation zu beheben und sicherzustellen, dass sensible Vorgänge wie Zahlungen und Formularübermittlungen während einer Weiterleitung nicht falsch gehandhabt werden.

Es ist der Unterschied zwischen einer vagen Anweisung wie "Geh dorthin" und einem präzisen Befehl wie "Nimm alles, was du mir geben wolltest, und gib es stattdessen dieser anderen Person."

Wenn Sie als Entwickler robuste Webanwendungen erstellen, insbesondere mit APIs, die Zahlungen, Anmeldungen oder Datenübermittlungen verarbeiten, ist das Verständnis von 307 unerlässlich.

Und bevor wir uns in die technischen Details vertiefen: Wenn Sie APIs entwickeln oder testen, die komplexe Weiterleitungsabläufe beinhalten, benötigen Sie ein Tool, das diese Nuancen handhaben kann. Laden Sie Apidog kostenlos herunter; es ist eine All-in-One-API-Plattform, mit der Sie verschiedene Weiterleitungstypen einfach testen, überprüfen können, ob Anfragemethoden beibehalten werden, und sicherstellen können, dass die kritischen Pfade Ihrer Anwendung sicher und zuverlässig sind.

button

Krempeln wir nun die Ärmel hoch und erkunden alles über den Statuscode 307 Temporary Redirect.

Das Problem: Die Unklarheit der 302-Weiterleitung

Um 307 zu verstehen, müssen wir zuerst den Fehler verstehen, den es beheben sollte. Die Geschichte beginnt mit der ursprünglichen temporären Weiterleitung, 302 Found.

Die HTTP/1.0-Spezifikation für 302 war unklar. Sie besagte, dass der Client die Weiterleitung durchführen sollte, aber sie sagte nicht explizit, ob die weitergeleitete Anfrage dieselbe HTTP-Methode (z. B. POST, PUT) wie die ursprüngliche Anfrage verwenden sollte.

Dies führte zu einem Problem: Aus Sicherheitsgründen implementierten die meisten Browserhersteller 302, indem sie die Methode der weitergeleiteten Anfrage in GET änderten. Dies war für die meisten grundlegenden Web-Browsing-Vorgänge sinnvoll, führte aber bei programmatischen oder API-gesteuerten Interaktionen zu Katastrophen.

Das Katastrophenszenario:

  1. Ein Client POSTet Formulardaten an /submit-payment.
  2. Der Server antwortet mit 302 Found und einem Location: /confirm-Header.
  3. Der Browser folgt der Weiterleitung, indem er eine GET-Anfrage an /confirm sendet.
  4. Die sensiblen POST-Daten gehen verloren. Der /confirm-Endpunkt, der eine GET-Anfrage erwartet, zeigt möglicherweise eine Seite an, hat aber keine Ahnung, welche Zahlung bestätigt werden soll.

Der Statuscode 307 wurde in HTTP/1.1 eingeführt, um diese gefährliche Unklarheit ein für alle Mal zu beseitigen.

Was bedeutet HTTP 307 Temporary Redirect eigentlich?

Der Statuscode 307 Temporary Redirect ist eine klare, unmissverständliche Anweisung. Er zeigt an, dass sich die Zielressource vorübergehend unter einer anderen URI befindet, und der User-Agent DARF die in der ursprünglichen Anfrage verwendete Anfragemethode bei der weitergeleiteten Anfrage NICHT ändern.

War die ursprüngliche Anfrage eine POST-Anfrage, muss die weitergeleitete Anfrage ebenfalls eine POST-Anfrage sein. War es eine PUT-Anfrage, muss sie eine PUT-Anfrage bleiben. Methode und Body müssen identisch sein.

Eine typische 307-Antwort sieht so aus:

HTTP/1.1 307 Temporary RedirectLocation: <https://auth.example.com/3d-secureContent-Type:> text/htmlContent-Length: 125
<html><head><title>307 Temporäre Weiterleitung</title></head><body><center><h1>307 Temporäre Weiterleitung</h1></center></body></html>

Der Schlüssel ist, wie bei allen Weiterleitungen, der Location: <https://auth.example.com/3d-secure>-Header. Die Magie liegt in der semantischen Garantie des 307-Statuscodes selbst.

Warum gibt es Weiterleitungen in HTTP?

Weiterleitungen existieren, um Servern und Clients zu helfen, Änderungen in der Ressourcenverfügbarkeit zu kommunizieren, ohne die Benutzererfahrung zu beeinträchtigen.

Einige gängige Szenarien sind:

Ohne Weiterleitungen würden Benutzer Fehlermeldungen sehen, wann immer Ressourcen verschoben werden.

307 vs. 302: Der entscheidende Unterschied

Dies ist der wichtigste Unterschied. Der Unterschied liegt in der Methodenerhaltung.

Merkmal 302 Found 307 Temporary Redirect
Originalspezifikation Unklar bezüglich Methodenänderung. Verbietet explizit Methodenänderung.
Typisches Browserverhalten Ändert POST zu GET. Dies ist der entscheidende Unterschied. Behält die ursprüngliche Methode bei (POST bleibt POST).
Sicherheit Unsicher. Sollte nicht nach einer nicht-idempotenten Anfrage (wie POST) verwendet werden. Sicher. Speziell für nicht-idempotente Anfragen konzipiert.
Analogie "Die von Ihnen gesendeten Informationen wurden empfangen. Bitte gehen Sie nun zu dieser neuen Seite, um das Ergebnis zu sehen." (Die Daten werden übergeben). "Bitte senden Sie genau dasselbe Informationspaket an diese neue Adresse erneut." (Die Daten werden umgeleitet).

Wann sollte man welchen verwenden?

Wie 307 Temporary Redirect funktioniert

Hier ist ein vereinfachter Ablauf:

1. Client fordert eine Ressource an:

POST /checkout HTTP/1.1
Host: shop.example.com

2.  Server antwortet mit 307 Temporary Redirect:

HTTP/1.1 307 Temporary Redirect
Location: <https://secure.example.com/checkout>

3.  Client wiederholt die POST-Anfrage am neuen Ort:

POST /checkout HTTP/1.1
Host: secure.example.com

Der entscheidende Punkt: Die Anfragemethode und der Body bleiben erhalten.

Ein Praxisbeispiel: Der Zahlungsablauf

Gehen wir das Zahlungsszenario durch, um 307 in Aktion zu sehen.

1. Der ursprüngliche POST: Der Benutzer übermittelt das Zahlungsformular. Der Browser sendet:

POST /checkout/payment HTTP/1.1Host: shop.example.comContent-Type: application/x-www-form-urlencoded

card_number=4111...&expiry=12/25&cvc=123

2.  Die 307-Antwort des Servers: Der Server des Shops muss an das 3D-Secure-System der Bank übergeben. Er antwortet:

HTTP/1.1 307 Temporary RedirectLocation: <https://api.bank.com/3d-secure/authenticate>

3.  Der beibehaltene POST: Der Browser empfängt die 307-Antwort. Da die Spezifikation eindeutig ist, weiß er, dass er die exakt gleiche POST-Anfrage mit dem exakt gleichen Body an den neuen Ort erneut senden muss.

POST /3d-secure/authenticate HTTP/1.1Host: api.bank.comContent-Type: application/x-www-form-urlencoded

card_number=4111...&expiry=12/25&cvc=123

4.  Das Endergebnis: Die API der Bank empfängt die Zahlungsdetails direkt, führt die Authentifizierung durch und antwortet dann dem Client mit den nächsten Schritten (wahrscheinlich einer 303- oder 302-Weiterleitung zurück zur Bestätigungsseite des Shops).

Dieser Ablauf stellt sicher, dass keine sensiblen Daten zwischen dem Shop und der Bank verloren gehen.

Wann sollten Sie 307 vs. 301 oder 302 verwenden?

Beste Faustregel:

Vorteile der Verwendung von 307 Temporary Redirect

Nachteile und häufige Missverständnisse

307 und API-Entwicklung

In der Welt der APIs spielt 307 eine wichtige Rolle:

Ohne 307 riskieren Entwickler, dass Clients den Anfragetyp unbeabsichtigt ändern.

Testen von 307-Weiterleitungen mit Apidog

Apidog Werbematerial

Dieses Verhalten zu testen ist entscheidend. Wenn Sie APIs entwickeln oder testen, möchten Sie wahrscheinlich sehen, wie Ihr Client 307-Antworten verarbeitet. Sie müssen sicherstellen, dass Ihr Client 307-Antworten korrekt verarbeitet, indem er Methode und Body beibehält. Apidog ist das perfekte Tool dafür.

Mit Apidog können Sie:

  1. Erstellen Sie eine POST-Anfrage: Richten Sie einfach eine POST-Anfrage mit einem JSON- oder Formular-Daten-Body an Ihren Endpunkt ein.
  2. Simulieren Sie eine 307-Antwort: Konfigurieren Sie Ihren Server-Mock in Apidog so, dass er eine 307 Temporary Redirect mit einem Location-Header zurückgibt.
  3. Beobachten Sie die automatische Weiterleitung: Apidog folgt der Weiterleitung automatisch. Der entscheidende Test ist die Überprüfung des Anfrageprotokolls für die zweite Anfrage. Wurde die POST-Methode beibehalten? Wurde genau derselbe Body gesendet?
  4. Vergleich mit 302: Führen Sie denselben Test durch, aber lassen Sie Ihren Mock stattdessen eine 302 zurückgeben. Beobachten Sie, wie Apidog (das sich wie ein Standardbrowser verhält) die Methode in GET ändert und den Body verwirft. Diese visuelle Demonstration veranschaulicht den Unterschied perfekt.
  5. Testen Sie API-Clients: Wenn Sie einen programmatischen API-Client (z. B. in Node.js, Python) entwickeln, können Sie Apidog verwenden, um den Server zu simulieren und sicherzustellen, dass Ihr Client-Code 307-Antworten korrekt verarbeitet, indem er die Methode beibehält.
button

Dieses Testniveau stellt sicher, dass kritische Operationen wie Zahlungen und Anmeldungen in der Produktion nicht fehlschlagen. Laden Sie Apidog kostenlos herunter und versuchen Sie noch heute, eine 307-Antwort zu simulieren. Es ist eine großartige Möglichkeit, Ihre Anwendungen unter realen Weiterleitungsbedingungen zu testen.

SEO-Implikationen von 307 Temporary Redirect

Aus SEO-Sicht:

Wenn Sie 307 anstelle von 301 verwenden, riskieren Sie den Verlust langfristiger SEO-Vorteile.

307 vs. 308 Permanent Redirect

So wie 307 das strikte Gegenstück zu 302 ist, hat es einen Bruder für dauerhafte Verschiebungen: 308 Permanent Redirect.

Verwenden Sie 307 für temporäre Wartung, A/B-Tests oder Failover-Szenarien. Verwenden Sie 308, wenn Sie die URL eines Endpunkts, der Nicht-GET-Anfragen erwartet, dauerhaft ändern.

Sicherheitsaspekte bei 307

Aus Sicherheitsgründen ist 307 oft sicherer als 302, da es eine Anforderungsmanipulation vermeidet. Beachten Sie jedoch:

Implementierung und Best Practices

Alternativen zu 307 Temporary Redirect

Je nach Anwendungsfall:

Fazit: Die Garantie der Sicherheit

Der HTTP-Statuscode 307 Temporary Redirect ist ein Beweis für die Entwicklung des Webs hin zu größerer Präzision und Sicherheit. Er löste eine kritische Unklarheit im Protokoll, die zu Datenverlust und Sicherheitslücken hätte führen können.

Der 307 Temporary Redirect Statuscode ist mehr als nur eine weitere Zahl in der HTTP-Spezifikation. Er löst reale Probleme, indem er sicherstellt, dass Anfragemethoden und -bodies bei Weiterleitungen intakt bleiben.

Während 302 und 303 ihre Berechtigung haben, bietet der 307 eine entscheidende Garantie: dass eine Anfrage genau wie beabsichtigt zugestellt wird, selbst wenn sich ihr Ziel vorübergehend ändert. Dies macht ihn unverzichtbar für den Aufbau zuverlässiger, sicherer Webanwendungen, die sensible Vorgänge verarbeiten.

Das Verständnis der nuancierten Unterschiede zwischen diesen Weiterleitungscodes ist ein Zeichen eines erfahrenen Entwicklers. Und wenn es darum geht, zu testen und zu validieren, dass Ihre Anwendungen diese Weiterleitungen korrekt handhaben, bietet ein leistungsstarkes Tool wie Apidog die nötige Sichtbarkeit und Kontrolle, um sicherzustellen, dass Ihre Weiterleitungen nicht nur funktionieren, sondern präzise funktionieren.

button

Praktizieren Sie API Design-First in Apidog

Entdecken Sie eine einfachere Möglichkeit, APIs zu erstellen und zu nutzen