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.
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:
- Ein Client
POSTet Formulardaten an/submit-payment. - Der Server antwortet mit
302 Foundund einemLocation: /confirm-Header. - Der Browser folgt der Weiterleitung, indem er eine GET-Anfrage an
/confirmsendet. - Die sensiblen
POST-Daten gehen verloren. Der/confirm-Endpunkt, der eineGET-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:
- Website-Migrationen → Umzug von
http://nachhttps://. - Temporäre Ausfälle → Umleiten des Datenverkehrs während der Serverwartung.
- API-Versionierung → Senden von Clients zu einem neueren temporären Endpunkt.
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?
- Verwenden Sie
302 Found, wenn Sie nach einem POST weiterleiten möchten, die eigentliche Datenübermittlung jedoch abgeschlossen ist und die Weiterleitung lediglich dazu dient, eine Ergebnisseite anzuzeigen. (Obwohl303 See Otherhierfür oft noch besser ist). - Verwenden Sie
307 Temporary Redirect, wenn die ursprüngliche Anfrage (und ihre Methode/ihr Body) an eine andere URI erneut gesendet werden muss, um die Aktion abzuschließen. Dies ist üblich bei Authentifizierungsabläufen, Zahlungsgateways und API-Ketten.
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?
- 301 Moved Permanently → Wenn sich der Ressourcenstandort nie wieder ändern wird.
- 302 Found → Wenn sich die Ressource vorübergehend an einem anderen Ort befindet, aber die Methodenerhaltung nicht kritisch ist.
- 307 Temporary Redirect → Wenn sich die Ressource vorübergehend an einem anderen Ort befindet und Sie die HTTP-Methode unbedingt beibehalten müssen.
Beste Faustregel:
- Verwenden Sie 301 für dauerhafte Änderungen.
- Verwenden Sie 307 für temporäre Verschiebungen, die sensible Operationen (wie POST-Anfragen) beinhalten.
Vorteile der Verwendung von 307 Temporary Redirect
- Vorhersagbarkeit → Die Anfragemethode bleibt immer erhalten.
- Sicherheit → Verhindert versehentliche Methoden-Downgrades (z. B. POST wird zu GET).
- Entwicklerklarheit → Clients wissen genau, welches Verhalten zu erwarten ist.
Nachteile und häufige Missverständnisse
- Einige ältere Clients unterstützen 307 möglicherweise nicht korrekt.
- Entwickler verwechseln 307 manchmal mit 302, was zu unbeabsichtigtem Verhalten führt.
- SEO-Experten interpretieren 307 gelegentlich fälschlicherweise als Äquivalent zu 301 – das ist es nicht.
307 und API-Entwicklung
In der Welt der APIs spielt 307 eine wichtige Rolle:
- Stellt sicher, dass nicht-idempotente Anfragen (wie POST) konsistent bleiben.
- Hilft API-Gateways, den Datenverkehr bei temporären Änderungen sicher zu leiten.
- Bietet eine sichere Möglichkeit zur Handhabung von Wartungsfenstern.
Ohne 307 riskieren Entwickler, dass Clients den Anfragetyp unbeabsichtigt ändern.
Testen von 307-Weiterleitungen mit Apidog

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:
- Erstellen Sie eine POST-Anfrage: Richten Sie einfach eine POST-Anfrage mit einem JSON- oder Formular-Daten-Body an Ihren Endpunkt ein.
- Simulieren Sie eine 307-Antwort: Konfigurieren Sie Ihren Server-Mock in Apidog so, dass er eine
307 Temporary Redirectmit einemLocation-Header zurückgibt. - 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?
- Vergleich mit 302: Führen Sie denselben Test durch, aber lassen Sie Ihren Mock stattdessen eine
302zurü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. - 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.
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:
- 307 signalisiert Suchmaschinen, dass die Weiterleitung temporär ist.
- Im Gegensatz zu 301 übertragen Suchmaschinen keine Link-Autorität (PageRank) auf die neue URL.
- Dies ist perfekt für A/B-Tests, Werbeaktionen oder kurzfristige Kampagnen.
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.
307 Temporary Redirect: "Senden Sie die gleiche Anfrage temporär an diese andere URL erneut."308 Permanent Redirect: "Senden Sie die gleiche Anfrage dauerhaft an diese andere URL erneut. Aktualisieren Sie Ihre Aufzeichnungen."
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:
- Bösartige Weiterleitungen könnten Benutzer immer noch auf Phishing-Websites führen.
- Verwenden Sie immer HTTPS im
Location-Header, um Downgrade-Angriffe zu verhindern.
Implementierung und Best Practices
- Für Server-Entwickler: Wenn Sie eine nicht-idempotente Anfrage (POST, PUT, DELETE) temporär weiterleiten müssen, verwenden Sie
307. Es ist die sicherste und semantisch korrekteste Wahl. - Für Client-Entwickler: Stellen Sie sicher, dass Ihre HTTP-Client-Bibliothek (z. B. Axios, Requests)
307-Antworten korrekt verarbeitet, indem sie die ursprüngliche Anfrage an den neuen Speicherort erneut sendet. Die meisten modernen Bibliotheken tun dies korrekt. - Bevorzugen Sie immer Präzision: Verwenden Sie standardmäßig
307anstelle von302, wenn Sie sicher sind, dass die Methode beibehalten werden muss. Dies eliminiert Unklarheiten.
Alternativen zu 307 Temporary Redirect
Je nach Anwendungsfall:
- Verwenden Sie 308 Permanent Redirect, wenn die Verschiebung dauerhaft ist und Sie die Methodenerhaltung benötigen.
- Verwenden Sie 302 Found, wenn die Methode keine Rolle spielt und die Abwärtskompatibilität wichtiger ist.
- Verwenden Sie 301 Moved Permanently für dauerhafte Umzüge, bei denen SEO Priorität hat.
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.
