Gated-execute on HTTP 301 vs 308

Both 301 and 308 mean the same thing: the resource has moved permanently. They differ in one way. When a client follows a 301, it is allowed to change a POST into a GET. When it follows a 308, it must keep the original method and body. Both are cacheable by default, and both are currently defined in RFC 9110.

What each means. RFC 9110 uses the same wording for both: 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" (301: §15.4.2, 308: §15.4.9, https://www.rfc-editor.org/rfc/rfc9110.html). For both, the server SHOULD send a Location header with the new URI, and the client MAY follow it automatically.

How the method and body are treated.

• 301: RFC 9110 says that "for historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request." If that is unwanted, it says to use 308 instead.
• Why: HTTP/1.0 originally defined 301 and 302 as keeping the method. Early clients disagreed on whether to resend POST as POST or as GET, and in practice they settled on GET. So 307 and 308 were added "to unambiguously indicate method-preserving redirects," and the text for 301 and 302 was changed to allow POST to become GET.
• The general redirect rule: a client following a redirect SHOULD resend the original request. It changes the method only if the status code's rules allow it. If the method becomes GET or HEAD, it removes content-related headers such as Content-Type and Content-Length, which means the body is dropped.
• 308: it is the method-preserving version of 301. RFC 7538, which introduced it, says it "does not allow changing the request method from POST to GET" (https://www.rfc-editor.org/rfc/rfc7538.html).
• In practice: following a 301, a POST may arrive as a GET with no body. Following a 308, the same method and body are resent to the new URI. MDN says "The request method and the body will not be modified by the client in the redirected request" (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/308).

The sources disagree on 301. The same MDN page says that "A 301 Moved Permanently requires the request method and the body to remain unchanged," and treats switching to GET as something older clients get wrong. That conflicts with RFC 9110, which explicitly allows POST to become GET. The RFC is the normative text, so I've followed it. Elsewhere, the same MDN page describes 301 as a code "that may modify the request method when it is not a GET," which matches the RFC.

Caching. RFC 9110 calls both 301 and 308 "heuristically cacheable", unless the method definition or explicit cache controls say otherwise. RFC 7538 had described 308 as "cacheable by default."

Where each is specified.

• 301: RFC 9110 §15.4.2.
• 308: RFC 9110 §15.4.9.
• Older documents: RFC 9110 replaces (obsoletes) RFC 7231 and RFC 7538. RFC 7538 had itself replaced the experimental RFC 7238 without technical changes.
• Deployment caveat: RFC 9110 notes that 308 is "much younger (June 2014)" than the other redirect codes and "might not be recognized everywhere." RFC 7538 warns that a client that doesn't recognize 308 treats it like 300 (Multiple Choices), so automatic redirection isn't guaranteed.

{"evidence": [
{"claim": "301 means the target 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 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": "When following a 301, a user agent may change POST to GET; 308 should be used 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": "307 and 308 were added to indicate method-preserving redirects without ambiguity.", "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": "If a redirect changes the method to GET or HEAD, content-specific headers are removed, so the body is dropped.", "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": "308 is like 301 except that it 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": "With 308, the client keeps the method and body unchanged in the redirected request.", "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 says 301 requires the method and body to stay unchanged, which conflicts with RFC 9110 allowing POST to become GET.", "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": "301 and 308 are both heuristically cacheable unless the method or explicit cache controls say otherwise.", "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 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 [RFC7234], Section 4.2.2).", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "RFC 9110 is the current specification and obsoletes RFC 7231 and RFC 7538.", "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 by every client.", "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"}
]}