Redirects 301, 302, 307 and 308: which ones preserve the request method

What it is

RFC 9110 defines four codes meaning "the resource is at the URI in Location" and one that points elsewhere:

• 301 Moved Permanently: for historical reasons a user agent MAY change POST to GET on the follow-up request. Heuristically cacheable.
• 302 Found: temporary; the same POST-to-GET note applies. Not heuristically cacheable.
• 303 See Other: the client performs a retrieval (GET or HEAD) of a different resource; the post-redirect-get pattern for forms.
• 307 Temporary Redirect: the user agent MUST NOT change the method; not heuristically cacheable.
• 308 Permanent Redirect: MUST NOT change the method; heuristically cacheable. RFC 9110 notes that it is much younger than its siblings and might not be recognised everywhere.

RFC 9110 also describes what a client does when following: replace the target URI, drop automatically generated and connection-specific fields, consider dropping Authorization and Cookie, change the method only where the status code says so, and remove content headers if the method became GET. Clients should detect loops; an earlier specification suggested a limit of five hops.

Why it matters

An API that answers a POST with 301 or 302 cannot know whether the client will re-POST the body or issue a GET; MDN's page on 302 says to use 307 instead to avoid user agents modifying the request. Permanent codes may be reused by caches without asking the origin, so a wrong 301 or 308 keeps sending clients to the wrong place after the fix.

How to apply

• Resource moved for good and any method may arrive: 308. Only GET and HEAD traffic and old clients matter: 301.
• Temporary detour where method and body must survive (maintenance, canary): 307.
• After a successful browser form POST: 303 to the result page, so a reload does not resubmit.
• Retired resource without successor: 410, not a redirect to the home page.
• Set an explicit Cache-Control on permanent redirects to bound the life of a mistake.
• Test with curl -v -L -d '' URL and watch the method per hop: curl switches to GET after 301, 302 and 303 unless --post301, --post302 or --post303 is given. -X POST -L cannot show the change, because curl documents that a method set with -X is used for all requests.

Pitfalls

Redirecting an http:// POST endpoint to HTTPS with 301 loses or re-issues bodies depending on the client. Redirect chains multiply round trips and cache behaviour. Clients commonly drop Authorization when a redirect leads to another host, as RFC 9110 tells them to consider; curl documents that it withholds credentials from other hostnames unless --location-trusted is given, so a redirected authenticated request may arrive without its token.