Propose-select on HTTP 301 vs 308

Short answer: 301 (Moved Permanently) and 308 (Permanent Redirect) both tell the client that the resource has permanently moved to the URI in the Location header. They differ in what the client may do with the request method and body when it follows the redirect. After a 301, a client may turn a POST into a GET. After a 308, it may not.

301 Moved Permanently

• Meaning: The target resource has been assigned a new permanent URI. Future references should use one of the URIs the server sent. The server should send a Location header, and the user agent may follow it automatically.
• Method and body: RFC 9110 says "For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request." Early clients split on whether to resend a POST as POST or as GET, and practice converged on GET. RFC 9110 now permits the change but does not require it, so 301 does not reliably preserve the method. If the method becomes GET or HEAD, the client removes content-specific headers such as Content-Type and Content-Length. In practice this means the body is not resent.
• Cacheability: 301 is heuristically cacheable. A cache may store it without explicit freshness information, unless the method definition or explicit cache controls (Cache-Control, Expires) say otherwise.

308 Permanent Redirect

• Meaning: The same permanent-move meaning and Location handling as 301.

• Method and body: The method must not change from POST to GET. RFC 7538, the original 308 spec, describes it as similar to 301 "except that it does not allow changing the request method from POST to GET". RFC 9110 says 307 and 308 were added "to unambiguously indicate method-preserving redirects". The client therefore repeats the request with the same method and the same body. RFC 9110's rule about removing content headers applies only when the method has been changed to GET or HEAD, which does not happen with 308.

  • Caveat: RFC 9110's 308 section does not itself contain an explicit "MUST NOT change the method" sentence. The method-preserving rule comes from RFC 9110's §15.4 note, the general redirect rules, and RFC 7538's wording. The explicit prohibition is in the 307 text.
• Cacheability: Also heuristically cacheable, with the same wording as 301. RFC 7538 (2015) used the older phrase "cacheable by default". I read this as a terminology difference rather than a substantive one, but I did not open RFC 9111 to confirm.
• Deployment caveat: RFC 9110 notes 308 is much younger (June 2014) than its sibling codes and might not be recognized everywhere. Under RFC 7538, a client that does not recognize 308 treats it like 300 (Multiple Choices) and may not redirect automatically. Servers should use 308 only when they are confident clients understand it, or when falling back to 300 behavior is acceptable.

Where each is specified today

• Both are in RFC 9110 (HTTP Semantics, June 2022, STD 97). 301 is in §15.4.2 and 308 is in §15.4.9. The general redirect-following rules are in §15.4.
• 301 was previously in RFC 7231. 308 was originally defined in RFC 7538 (2015), which followed the experimental RFC 7238.
• RFC 9110 obsoletes both RFC 7231 and RFC 7538. RFC 7538 is therefore historical, though still useful for background.
• RFC 9110 refers to HTTP Caching (RFC 9111) for the heuristic-cacheability rules. I did not open RFC 9111.

Practical guidance: Use 308 for a permanent move where POST, PUT or DELETE must keep their method and body, such as an API endpoint. 301 is fine for permanent moves of ordinary GET pages. I did not check whether a newer RFC has superseded RFC 9110.

{"evidence": [
{"claim": "301 means the resource has a new permanent URI and future references should use it; defined in RFC 9110 section 15.4.2", "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; 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 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 means the resource has a new permanent URI, with the same meaning as 301; defined in RFC 9110 section 15.4.9", "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 responses are heuristically cacheable in RFC 9110", "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": "307 and 308 were added to unambiguously indicate method-preserving redirects, while 301 and 302 allow POST to be redirected as 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": "When the method is changed to GET or HEAD on redirect, content-specific headers are removed (so this applies to 301 but not to a method-preserving 308)", "quote": "If the request method has been changed to GET or HEAD, remove content-specific header fields, including (but not limited to)", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "RFC 9110 obsoletes RFC 7538, the original 308 specification, so RFC 9110 is the current specification", "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 9110 notes 308 is younger than its sibling codes and might 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 (2015) defined 308 as the same as 301 except 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": "RFC 7538 said 308 was 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": "Deployment caveat: 308 is newer, so servers should only use it when clients are likely to 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"}
]}