Single on HTTP 301 vs 308

Short answer: 301 and 308 both mean "this resource has a new permanent URI". They differ in one respect. With 301, a client may change a POST to a GET when it follows the redirect. With 308, it may not.

What each means

• 301 (Moved Permanently): RFC 9110 says it "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 it to redirect automatically. (https://www.rfc-editor.org/rfc/rfc9110.html)
• 308 (Permanent Redirect): The wording is essentially identical. It also signals a new permanent URI, with the same Location handling. (https://www.rfc-editor.org/rfc/rfc9110.html)
• In both, the spec says a user agent with link-editing ability can permanently replace references to the old URI. It adds that this "is usually ignored unless the user agent is actively editing references".

Request method and body when following the redirect

• 301: RFC 9110 has a note saying "For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request." The same note says that if this behaviour is undesired, 308 can be used instead. In practice, a POST to a 301 URL may arrive at the new URL as a GET, and a GET normally carries no body. (https://www.rfc-editor.org/rfc/rfc9110.html)
• 308: The original RFC 7538 describes it as similar to 301 "except that it does not allow changing the request method from POST to GET." The method is therefore preserved. RFC 9110's 308 section does not repeat that rule. It states it only through the 301 note above. (https://www.rfc-editor.org/rfc/rfc7538.html)
• Body: I found no explicit sentence about body handling in either section I read. The expectation that a 308 client resends the same body is my inference from "method not changed". It matches how 307, the temporary counterpart, is described, where RFC 9110 says the user agent "MUST NOT change the request method". (https://www.rfc-editor.org/rfc/rfc9110.html)

Cacheability
Both are cacheable by default, but not unconditionally.

• RFC 9110 says a 301 response "is heuristically cacheable", unless the method definition or explicit cache controls say otherwise.
• It says exactly the same for 308. (https://www.rfc-editor.org/rfc/rfc9110.html)
• The older RFC 7538 worded this as "cacheable by default". (https://www.rfc-editor.org/rfc/rfc7538.html)
• Explicit Cache-Control or Expires headers can override the default for either code.

Where each is specified today

• Both are defined in RFC 9110 (HTTP Semantics, STD 97, June 2022). 301 is in section 15.4.2 and 308 is in section 15.4.9. (https://www.rfc-editor.org/rfc/rfc9110.html)
• RFC 9110 obsoletes RFC 7231, which defined 301 earlier. It also obsoletes RFC 7538, which defined 308. (https://www.rfc-editor.org/rfc/rfc9110.html)
• RFC 7538 was a standards-track document that carried over the experimental RFC 7238 with no technical changes. It is now obsolete and only of historical interest. (https://www.rfc-editor.org/rfc/rfc7538.html)

Compatibility caveat

• RFC 9110 notes that 308 "is much younger (June 2014) than its sibling codes and thus might not be recognized everywhere."
• RFC 7538 explains that unknown 3xx codes are treated like 300 (Multiple Choices), so automatic redirection is not guaranteed. It advises using 308 only when the server is confident the client understands it, or when falling back to 300 behaviour is harmless. (https://www.rfc-editor.org/rfc/rfc7538.html)

I could not open the rfc-editor info page for RFC 9110, which returned a 404. I therefore did not independently confirm that no later RFC has replaced it. I only confirmed that the RFC 9110 text I read is the one that obsoleted RFC 7538.

{"evidence": [
{"claim": "301 means the 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": "With 301, clients 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 is heuristically cacheable", "quote": "A 301 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 means a new permanent URI, same semantics as 301 for the target", "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 is heuristically cacheable", "quote": "A 308 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 might 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"},
{"claim": "308 differs from 301 in not allowing POST to be changed to GET", "quote": "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 originally 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 [RFC7234], Section 4.2.2).", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "RFC 9110 obsoletes RFC 7231 and RFC 7538, so it is the current specification of 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": "Unknown 3xx codes are treated like 300, so 308 use should be limited to clients that understand it", "quote": "Therefore, the use of status code 308 is restricted to cases where the server has sufficient confidence in the client's understanding the new code or when a fallback to the semantics of status code 300 is not problematic.", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "RFC 7538 made no technical changes from the experimental RFC 7238", "quote": "This specification contains no technical changes from the Experimental RFC 7238, which it obsoletes.", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "The temporary counterpart 307 explicitly forbids changing the method", "quote": "the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"}
]}