Plan-execute on HTTP 301 vs 308

Short version: 301 and 308 both mean "this resource has moved permanently". They differ in method handling. With 301, a client may turn a POST into a GET. With 308, the method and body stay the same. Both are specified in RFC 9110, and 308 first appeared in RFC 7538.

1. What each means

• 301 (Moved Permanently): RFC 9110 §15.4.2 says the 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." The server should send a Location header with the new URI, and the user agent "MAY use the Location field value for automatic redirection." (https://www.rfc-editor.org/rfc/rfc9110.html)
• 308 (Permanent Redirect): The semantics are the same, "permanent" and "new URI". RFC 9110 §15.4.9 uses the same wording as 301, and RFC 7538 §3 does too. (https://www.rfc-editor.org/rfc/rfc9110.html, https://www.rfc-editor.org/rfc/rfc7538.html)

2. Method and body handling

• 301: RFC 9110 says "For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request." It adds that if this is undesired, 308 can be used instead.
• Why 301 is ambiguous: HTTP/1.0 defined 301 as method-preserving. Early user agents split on whether to redirect POST as POST or as GET. "Prevailing practice eventually converged on changing the method to GET."
• 308: 307 and 308 "were later added to unambiguously indicate method-preserving redirects." RFC 7538 says 308 is "similar to 301 (Moved Permanently) … except that it does not allow changing the request method from POST to GET." RFC 7538 was written to add the missing permanent counterpart of 307. (https://www.rfc-editor.org/rfc/rfc7538.html)
• Body: A client that follows a 308 should resend the original request with the same method. Under the general redirect procedure in RFC 9110 §15.4, the client changes the method "according to the redirecting status code's semantics, if applicable." It removes content-specific headers such as Content-Type and Content-Length only "If the request method has been changed to GET or HEAD." That rule is why a 301 that turns POST into GET drops the body, while a 308 keeps the method and so keeps the body. This is my inference from those rules. RFC 9110 doesn't spell out "body preserved" for 308 in so many words.
• Wording: RFC 9110's 308 section doesn't repeat the "MUST NOT change the method" wording that its 307 section has. The method-preserving behavior for 308 comes from the §15.4 note and from RFC 7538.

3. Cacheability
Both are cacheable by default. RFC 9110 says "A 301 response is heuristically cacheable" and "A 308 response is heuristically cacheable". In each case this holds "unless otherwise indicated by the method definition or explicit cache controls." RFC 7538 had said "A 308 response is cacheable by default", and RFC 9110 now uses the term "heuristically cacheable."

4. Where each is specified

• Current specification: RFC 9110 (HTTP Semantics), §15.4.2 for 301 and §15.4.9 for 308. It obsoletes RFC 7231, which previously defined 301, and RFC 7538. (https://www.rfc-editor.org/rfc/rfc9110.html)
• Origin of 308: RFC 7538 (April 2015, Standards Track) introduced it. It "obsoletes" the earlier Experimental RFC 7238, with no technical changes.
• Obsolescence is stated in RFC 9110: The RFC 7538 page as I fetched it has no "Obsoleted by" line in its header. The obsoletion comes from RFC 9110's own header, so RFC 9110 is the authoritative source today.
• Deployment note: RFC 9110 says 308 is "much younger (June 2014) than its sibling codes and thus might not be recognized everywhere." RFC 7538 §4 explains that a client that doesn't understand 308 treats it like 300, so it may not redirect automatically.

I didn't consult MDN or other secondary sources, so everything above rests on the two RFCs.

{"evidence": [
{"claim": "301 means the target resource has a new permanent URI and future references should use it.", "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": "*Note:* For historical reasons, a user agent MAY change the", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "301 responses are heuristically cacheable.", "quote": "A 301 response is heuristically cacheable; i.e., unless otherwise", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 has the same permanent-move meaning as 301 and is defined in RFC 9110 section 15.4.9.", "quote": "The 308 (Permanent Redirect) status code indicates that the target", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 responses are heuristically cacheable.", "quote": "A 308 response is heuristically cacheable; i.e., unless otherwise", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "Historically, practice converged on changing POST to GET for 301/302, and 307/308 were added to unambiguously preserve the method.", "quote": "Prevailing practice", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "Content-specific headers are removed only when the redirect changes the method to GET or HEAD, which is why a method-preserving redirect keeps the body.", "quote": "If the request method has been changed to GET or HEAD, remove", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "RFC 9110 obsoletes RFC 7538 (and RFC 7231), making it the current specification for both codes.", "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 younger than its sibling codes and may not be recognized everywhere.", "quote": "This status code is much younger (June 2014) than its", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "RFC 7538 defines 308 as the missing permanent variant of 307.", "quote": "this specification adds the status code\n   308, defining this missing variant (Section 3).", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "308 is cacheable by default per RFC 7538.", "quote": "A 308 response is cacheable by default; i.e., unless otherwise", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "308 is like 301 except that it does not allow changing the method from POST to GET.", "quote": "except that it does not allow changing", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"}
]}