Propose-select on HTTP 301 vs 308

Short answer: 301 and 308 both say the resource has a new permanent URI. They differ in how a client may change the request method when it follows the redirect. With 301 a client may turn a POST into a GET. With 308 it may not. Both are now specified in RFC 9110 (HTTP Semantics, June 2022). This answer is based on RFC 9110, RFC 7538 and RFC 9111. I did not check how particular browsers or HTTP libraries behave.

What each one means

• 301 (Moved Permanently): 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 user agent may follow it automatically. Link-editing clients may permanently replace old references, but RFC 9110 says this suggestion is usually ignored. The exception is when the client is actively editing content, the connection is secured and the origin is a trusted authority for that content. (https://www.rfc-editor.org/rfc/rfc9110.html)
• 308 (Permanent Redirect): the meaning and the Location and link-editing wording are the same. The difference is the method rule below. (https://www.rfc-editor.org/rfc/rfc9110.html)

Request method and body when following the redirect

• 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. The history is that early clients differed on whether to resend a POST as POST or as GET. Practice converged on GET, and the spec now allows it. (https://www.rfc-editor.org/rfc/rfc9110.html)
• 308: RFC 9110 says 307 and 308 were added "to unambiguously indicate method-preserving redirects". RFC 7538 says 308 is like 301 "except that it does not allow changing the request method from POST to GET". A POST therefore stays a POST, and the body is expected to be resent to the new URI. (https://www.rfc-editor.org/rfc/rfc9110.html, https://www.rfc-editor.org/rfc/rfc7538.html)
• Body handling in RFC 9110: when following a redirect, the client should resend the original request message with some changes. One change applies only if the method became GET or HEAD: content-specific headers such as Content-Type and Content-Length are removed. So a 301 that was turned into a GET drops the body and its headers. A 308 does not change the method, so the content stays. RFC 9110 does not state the 308 body rule in one sentence. That part is my reading of the two passages together. Clients should also be careful about automatically redirecting methods that are not safe. (https://www.rfc-editor.org/rfc/rfc9110.html)
• Deployment caveat for 308: it is much newer (June 2014) and may not be recognized everywhere. A client that does not know a 3xx code treats it like 300 (Multiple Choices). Servers should use 308 only when they are confident the client understands it, or when falling back to 300 behavior is harmless. (https://www.rfc-editor.org/rfc/rfc9110.html, https://www.rfc-editor.org/rfc/rfc7538.html)

Cacheability
Both are cacheable by default, with no explicit cache headers needed. RFC 9110 calls each response "heuristically cacheable". The method definition or explicit cache controls can override that. RFC 9111 says "heuristically cacheable" is the newer name for what earlier specs called "cacheable by default". RFC 7538 used the older wording for 308. (https://www.rfc-editor.org/rfc/rfc9110.html, https://www.rfc-editor.org/rfc/rfc9111.html, https://www.rfc-editor.org/rfc/rfc7538.html)

Where they are specified today

• Both are in RFC 9110: 301 in section 15.4.2 and 308 in section 15.4.9.
• 308 was originally defined in RFC 7538 (2015). RFC 9110 obsoletes RFC 7538, so RFC 9110 is now the reference. RFC 7538 is still useful for its deployment considerations.
• The 301 definition was previously in RFC 7231, which RFC 9110 also obsoletes.
• Caching behavior is in RFC 9111.

Practical guidance: use 308 for permanent moves where the method and body must be preserved, such as POST or PUT endpoints or APIs. 301 is fine for ordinary page moves, where a GET after the redirect is acceptable. Both are cached heuristically, so a mistaken permanent redirect can stick in caches. Set explicit cache controls if you are not sure the move is final.

{"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 client 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": "308 has the same permanent-move meaning as 301", "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": "307 and 308 were added to unambiguously indicate method-preserving redirects, while 301/302 were adjusted to allow POST to become 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": "308 is like 301 but does not allow changing the method from 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": "Content-specific headers are removed only when the method has been changed to GET or HEAD", "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": "301 responses are 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 responses are 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": "'Heuristically cacheable' is the current name for what older specs called 'cacheable by default'", "quote": "Note that in previous specifications, heuristically cacheable response status codes were called \"cacheable by default\".", "url": "https://www.rfc-editor.org/rfc/rfc9111.html"},
{"claim": "RFC 7538 (original 308 spec) said 308 is 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 7538 and RFC 7231, so 301 and 308 are now specified in RFC 9110", "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 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"},
{"claim": "Unknown 3xx codes are treated like 300, so 308 use is restricted to cases where the client is trusted to understand it or the fallback is harmless", "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"}
]}