Redirects

307 and 308 redirects: the codes that keep the method

6 min readUpdated Sep 2026
A redirect does not only move a request to another address. It also decides what kind of request arrives there, and the older codes left that second decision to the client. The newer pair, 307 and 308, exists to take it back: whatever was sent to the old address is what the new address receives.

What keeping the method means

An ordinary page load is a GET. A submitted form, an API call, a webhook delivery is usually something else: a POST carrying a body, or a PUT, or a DELETE. When a redirect answers such a request, the client has to decide what to send to the address in the Location line, and history gave it room to decide badly. The redirects overview covers how loosely the old codes were specified; the practical residue is that a POST following a 301 or a 302 commonly arrives at its destination as a plain GET, with the body gone.

307 and 308, specified in RFC 9110, remove the room. A client following either one repeats the request as it was: same method, same body. Nothing is reinterpreted on the way.

Two pairs, one new property

The four codes line up as two pairs, and the pairs differ on exactly one axis.

  • Temporary: 302 and 307

    Both say the original address is still the right one. The difference is what happens to the request en route: 307 repeats it as sent, 302 leaves the client free to soften it to a GET.

  • Permanent: 301 and 308

    Both say the old address is finished and may be remembered as finished. Again the difference is the method: 308 carries it through, 301 does not promise to.

Everything else the redirects overview says about permanence applies unchanged here, including the caution that a permanent answer can be cached and is therefore hard to take back. 308 inherits that property in full: it is 301 with the ambiguity removed, not a milder version of it.

When the choice is mandatory

For a page a person clicks to, the old pair is usually fine: the request is a GET already, and there is nothing to preserve. The choice stops being a matter of taste the moment an address can be reached by anything other than an ordinary page load.

Form handlers are the everyday case. An endpoint that accepts a submission and later moves must redirect with 307 or 308, or every submission that follows the old address arrives stripped of its body. API endpoints and webhook receivers are the same case with quieter symptoms: the sender retries, the receiver logs a malformed request, and neither side thinks of the redirect between them.

Before adding any redirect, ask what besides a browser fetches the old address. If the honest answer is "nothing, ever", the old pair is enough; if there is any doubt, the new pair costs nothing and removes the doubt.

Versioned APIs put the same habit to work in the other direction. An endpoint retired in favour of a newer path often keeps a redirect for stragglers, and that redirect answers tools, scripts and integrations, never browsers. There the new pair is not an upgrade but the only correct choice, since every request it will ever see carries a method worth keeping.

Seeing it in a trace

The failure has a recognisable face: a form that worked yesterday now lands on a page as if nothing was submitted, or an API client starts receiving errors about missing parameters after a migration nobody told it about.

A trace makes the cause legible. Reading each hop with its status code, as covered under redirect tracing, shows where a 301 or 302 stands in the path of a request that carries a body. The status of the hop is the answer: if anything other than 307 or 308 answers a non-GET request, the method that leaves that hop may not be the one that was sent. Repeating the check with the actual method of the real traffic, not with a browser reload, is what makes the reading conclusive.

Chains raise the stakes, in the way the chains page describes: one loose hop anywhere in the sequence is enough, because the request that leaves it softened stays softened.

What the receiving side sees

The sending client is only half of the diagnosis, because the softened request does not error on its way. It errors on arrival, in somebody else's logs.

A handler expecting a POST and receiving a GET answers however it was written to answer: some return a 405, some render the empty form again, some accept the request and process a submission with nothing in it. An API endpoint behind the same redirect tends to log a valid call with missing parameters, which reads like a client-side bug and sends the investigation in the wrong direction. When symptoms of that shape appear soon after a migration, reading the redirect between the two sides is the cheap first check: the code of that one hop explains the whole picture, and no amount of debugging on either side will.

FAQ

When should I use 307 instead of 302?

Whenever the redirected address can receive anything besides an ordinary page load, and by default when you are unsure. The two codes say the same thing about permanence; 307 additionally promises the request survives as sent. For a plain link between pages the difference does not surface, which is why both remain in use.

Do I need 308 for a site move?

For pages fetched by browsers and crawlers, a 301 does the job and is the code most tooling expects. 308 earns its place where moved addresses also receive submissions or API traffic, because it is the permanent code that keeps those requests whole. Mixed sites can use both, each on the endpoints it fits.

Why does my form break after a redirect?

Almost always because a 301 or 302 stands between the form and its handler, and the client followed it with a GET carrying no body. The handler then sees an empty request. Tracing the submission address hop by hop shows the guilty line; changing that hop to 307 or 308, or pointing the form at the final address, removes it.

Are 307 and 308 supported everywhere?

They are standard HTTP codes specified in RFC 9110, and current browsers and mainstream clients follow them. The practical caution is about your own side: older scripts and libraries that special-case only 301 and 302 treat anything else as an error, which is worth checking before a migration rather than after.

Redirects, hop by hop

Status codes, chains and loops: this section follows a request until something answers it. The platform these pages describe is Bridge CDN, where an account is created.