Plan-execute-verify on HTTP 301 vs 308

Short version: 301 and 308 both mean "this resource has permanently moved." They differ in what a client may do with the request method and body when it follows the redirect. With 301 a client may turn a POST into a GET. With 308 it may not.

What each means. RFC 9110 defines both with the same wording. The response says the target resource "has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs." The server should send a Location header with the preferred new URI, and the client may follow it automatically (https://www.rfc-editor.org/rfc/rfc9110.html). Both sections also say a link-editing client can permanently replace references to the old URI. They add that this suggestion is usually ignored unless the client is actively editing content, the connection is secured, and the server is a trusted authority.

Method and body handling.

• 301: RFC 9110 keeps a historical loophole. A user agent MAY change the request method from POST to GET for the follow-up request. Its section 15.4 explains why. HTTP/1.0 defined 301 and 302 as method-preserving, but early clients split on whether to redirect a POST as POST or as GET. Practice eventually converged on GET, so 301 and 302 "have been adjusted to allow a POST request to be redirected as GET."
• 308: It was added to be the unambiguous method-preserving permanent redirect. RFC 7538 says it is like 301 "except that it does not allow changing the request method from POST to GET." RFC 9110 says 307 and 308 were added "to unambiguously indicate method-preserving redirects." It also points to 308 as the fix when POST-to-GET rewriting is undesired. A 308 client should therefore resend the same method (POST stays POST) with the same body.
• Body: RFC 9110's general redirect rules say that when the method has been changed to GET or HEAD, the client removes content-specific headers such as Content-Type and Content-Length. In practice, a 301 that becomes a GET drops the body. A 308 keeps the method, so the body is resent.
• Wording caveat: RFC 9110's own 308 section does not repeat the explicit "does not allow changing the method" sentence. The 307 section does state it as "MUST NOT change the request method." For 308, the method-preservation guarantee comes from RFC 7538's note plus RFC 9110's notes in the 301 section and section 15.4. I did not open MDN or any other secondary source, so the browser behaviour above comes only from the RFCs.

Cacheability. Both are cacheable. The wording differs between RFCs:

• RFC 9110 says each is "heuristically cacheable," meaning cacheable unless the method definition or explicit cache controls (such as Cache-Control or Expires) say otherwise.
• RFC 7538, the older 308 spec, says "cacheable by default," which is the same idea in older terms.

Where each is specified.

• Current spec: RFC 9110 (HTTP Semantics, June 2022), section 15.4.2 for 301 and section 15.4.9 for 308.
• Superseded specs: RFC 9110's header lists "Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, 7538, 7615, 7694" and the abstract confirms it. That means RFC 7231 (which defined 301) and RFC 7538 (which defined 308) are both obsolete. RFC 7538, from April 2015, was a standalone document for 308, and it in turn obsoleted the experimental RFC 7238.
• Still current: A search for anything obsoleting RFC 9110 turned up nothing, but I did not check the RFC index directly. I could not open the RFC Editor info page for RFC 7538 (it returned 404), so my obsolescence claim rests on RFC 9110's own header text.
• Deployment: RFC 9110 notes that 308 is much younger than its sibling codes and "might not be recognized everywhere." Section 4 of RFC 7538 covers this, so a server should be confident its clients understand 308.

Practical guidance. Use 308 when a permanent move must preserve the method and body, for example for API endpoints that take POST, PUT, or DELETE. 301 is fine for GET-only moves such as page URLs. Use 307 for a temporary method-preserving redirect.

A correction to my starting plan. The plan assumed RFC 9110 says "cacheable by default" and states "MUST NOT change the method" in the 308 section. Neither is in that section, so I followed the text I retrieved.

{"evidence": [
{"claim": "301 means the target resource has been assigned a new permanent URI (RFC 9110 section 15.4.2)", "quote": "The 301 (Moved Permanently) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "For 301, a user agent may change POST to GET, and 308 is the alternative if that is undesired", "quote": "For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "301 responses are cacheable (heuristically) in RFC 9110", "quote": "A 301 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 means the target resource has been assigned a new permanent URI (RFC 9110 section 15.4.9)", "quote": "The 308 (Permanent Redirect) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 responses are cacheable (heuristically) in RFC 9110", "quote": "A 308 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 was added to unambiguously indicate method-preserving redirects, while 301 was adjusted to allow POST to be redirected as GET", "quote": "307 (Temporary Redirect) and 308 (Permanent Redirect) [RFC7538] were later added to unambiguously indicate method-preserving redirects, and status codes 301 and 302 have been adjusted to allow a POST request to be redirected as GET.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "When the method becomes GET or HEAD, content-specific headers are removed when following a redirect", "quote": "If the request method has been changed to GET or HEAD, remove content-specific header fields, including (but not limited to) Content-Encoding, Content-Language, Content-Location, Content-Type, Content-Length, Digest, Last-Modified.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "RFC 7538 (original 308 spec) says 308 is like 301 but disallows changing POST to GET", "quote": "Note: This status code is similar to 301 (Moved Permanently) ([RFC7231], Section 6.4.2), except that it does not allow changing the request method from POST to GET.", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "RFC 7538 described 308 as cacheable by default", "quote": "A 308 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "RFC 9110 obsoletes RFC 7231 (which defined 301) and RFC 7538 (which defined 308)", "quote": "This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 is newer than other redirect codes and may not be recognized everywhere", "quote": "This status code is much younger (June 2014) than its sibling codes and thus might not be recognized everywhere.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"}
]}