Single on HTTP 301 vs 308

Short answer: 301 and 308 both say a resource has moved to a new permanent URI. The difference is the request method. When following a 301, a client may turn a POST into a GET, for historical reasons. A 308 exists to rule that out: the same method and body are sent to the new location. Both are cacheable by default (the spec calls this "heuristically cacheable"), and both are now defined in RFC 9110, HTTP Semantics.

What each one means. RFC 9110 uses the same wording for both. 301 (Moved Permanently) means "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" (https://www.rfc-editor.org/rfc/rfc9110.html, §15.4.2). 308 (Permanent Redirect) uses identical language (§15.4.9). For both, the server SHOULD send a Location header with the new URI, and the user agent MAY follow it automatically. Clients that can edit links (for example, authoring tools) may update their stored references, though RFC 9110 says this is usually ignored unless conditions such as a secured connection are met.

Request method and body.

• 301: RFC 9110 notes that "for historical reasons, a user agent MAY change the request method from POST to GET." If that is unwanted, it says to use 308 instead. Section 15.4 gives the history. HTTP/1.0 defined 301 and 302 as keeping the method, but common practice moved to switching to GET. So 307 and 308 were added to mean "keep the method," and 301 and 302 were adjusted to allow POST to become GET.
• How redirects are followed in general: the user agent SHOULD resend the original request with some changes. It replaces the target URI, removes certain automatically added headers, changes the method only if the status code's meaning calls for it, and removes headers that describe the body (such as Content-Type and Content-Length) only if the method became GET or HEAD.
• 308: the method and body are therefore kept. RFC 7538, which defined 308 before RFC 9110, says 308 "does not allow changing the request method from POST to GET" (https://www.rfc-editor.org/rfc/rfc7538.html). One detail: the 308 section of RFC 9110 that I fetched does not repeat this as an explicit "MUST NOT." That wording appears only for 307. For 308 the rule comes from the §15.4 history note and from RFC 7538. I looked for an erratum on this and didn't find one.
• Where sources disagree: MDN's 308 page says the method and body "will not be modified" under 308. It also says 301 "requires the request method and the body to remain unchanged," and calls switching to GET incorrect behaviour by older clients (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/308). MDN's redirections guide likewise says the spec "did not intend to allow method changes" (https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Redirections). RFC 9110 explicitly allows POST to become GET on a 301, so it is the authoritative source here. MDN's own table is more careful: it says non-GET methods "may or may not be changed to GET."

Caching. RFC 9110 says each response is "heuristically cacheable." That means it can be cached unless the method definition or explicit cache controls say otherwise (see RFC 9111 §4.2.2). RFC 7538 called 308 "cacheable by default."

Where they are specified. Both are in RFC 9110 (June 2014 for 308's origin aside, RFC 9110 itself is Internet Standard STD 97): 301 in §15.4.2 and 308 in §15.4.9. RFC 9110 replaces RFC 7231 (the old home of 301) and RFC 7538 (the old home of 308, April 2015, which itself replaced the experimental RFC 7238). RFC 9110 lists "no changes" from RFC 7538. It also warns that 308 is much newer than 301 (from June 2014) and "might not be recognized everywhere," pointing to RFC 7538 §4 for deployment advice. Under the older rules, clients were to treat an unknown 3xx code like 300 (Multiple Choices).

{"evidence": [
{"claim": "301 means the resource has a new permanent URI that future references should use.", "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": "308 has the same permanent-move meaning.", "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": "With 301, a user agent may change POST to GET; 308 is the alternative if that is unwanted.", "quote": "If this behavior is undesired, the 308 (Permanent Redirect) status code can be used instead.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "307 and 308 were added to mean method-preserving redirects, and 301/302 were adjusted to allow POST to become GET.", "quote": "were later added to unambiguously indicate method-preserving", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "When following a redirect, the user agent resends the original request and changes the method only if the status code's meaning calls for it.", "quote": "Change the request method according to the redirecting status code's semantics, if applicable.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "RFC 7538 says 308 is like 301 but does not allow 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": "A 301 response 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": "A 308 response 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": "RFC 9110 replaces RFC 7231 and RFC 7538, among others.", "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": "RFC 7538 replaced the experimental RFC 7238 with no technical changes.", "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": "Under the older rules, clients treat an unknown 3xx code like 300, so servers cannot rely on automatic redirection for 308.", "quote": "Thus, servers will not be able to rely on automatic redirection happening similar to status codes 301, 302, or 307.", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "MDN says the method and body are not changed under 308.", "quote": "The request method and the body will not be modified by the client in the redirected request.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/308"},
{"claim": "MDN's 308 page describes 301 as requiring an unchanged method, which conflicts with RFC 9110.", "quote": "A 301 Moved Permanently requires the request method and the body to remain unchanged when redirection is performed, but this is incorrectly handled by older clients to use the GET method instead.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/308"},
{"claim": "MDN's redirections guide says the spec did not intend method changes and that 308 was created to remove the ambiguity.", "quote": "308 was created to remove the ambiguity of the behavior when using non-GET methods.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Redirections"}
]}