De meeste redirects werken op het oog hetzelfde. Je vraagt een pagina aan, wordt omgeleid, en de browser doet wat nodig is. Maar onder de motorkap zit verschil. Vooral als het om de HTTP-methode gaat.
Statuscode 307 is er voor situaties waarin je een verzoek wilt doorsturen, maar wél wilt dat de oorspronkelijke methode en de inhoud van het verzoek blijven zoals ze zijn. Dus geen POST die verandert in een GET. Geen lege body die verloren gaat. Gewoon dezelfde actie, maar op een andere plek.
Waarom niet gewoon 302?
Dat is precies het punt. 302 was nooit ontworpen om methodes te behouden. In de praktijk deden sommige clients dat wél, anderen niet. Resultaat: inconsistent gedrag, afhankelijk van de browser of bibliotheek.
307 is de strakkere, correctere opvolger. Hij maakt geen aannames. Wat binnenkomt als POST, gaat eruit als POST. Hetzelfde voor PUT, DELETE of PATCH. Dat maakt ‘m geschikt voor moderne toepassingen waar betrouwbaarheid telt.
Wanneer gebruik je een 307 redirect?
Denk aan een API die tijdelijk via een andere endpoint loopt. Of een formulierverwerking die wordt verplaatst zonder dat je gebruikers iets merken. Je wilt dat alles exact hetzelfde doorgaat, alleen via een ander pad.
Belangrijk: het is een tijdelijke omleiding. Als de verhuizing permanent is, kijk je naar 308. Maar voor alles met een tijdelijk karakter, waarbij methodebehoud cruciaal is, zit je met 307 goed.
Wat gebeurt er technisch?
Een client stuurt een POST naar /verwerk. De server reageert met:
HTTP/1.1 307 Temporary Redirect
Location: /tijdelijke-endpoint
De client is verplicht om datzelfde POST-verzoek nogmaals uit te voeren, maar nu naar het opgegeven adres. Geen conversie naar GET, geen extra prompts.
In tools als curl zie je het direct gebeuren. Ook in browser developer tools zie je netjes twee verzoeken: de originele, en de doorgestuurde met dezelfde methode.
Waarom zou je dit moeten weten?
Omdat een verkeerde redirect onzichtbare schade kan aanrichten. Je API lijkt te werken, maar POST-data verdwijnt onderweg. Of je formulierverwerking faalt omdat de methode plotseling veranderd is.
Als je routing, reverse proxies of tijdelijke API-paden beheert, wil je dat dit goed staat. En dat betekent: 307 gebruiken als je tijdelijke logica combineert met een strikte methode-eis.
Afsluiting
307 redirect is geen vervanger van 302. Het is een correctie. Een expliciete keuze voor consistentie in gedrag, vooral bij POST-gedreven systemen.
Gebruik je ‘m goed, dan merkt de gebruiker niets. Maar jij weet dat de onderliggende structuur betrouwbaar blijft, en dat telt. Voor formulieren, API’s en webshops is dit een typisch scenario waarin goede WordPress Hosting, WooCommerce Hosting en schaalbare Cloud Hosting écht het verschil maken.
