Gated-execute on HTTP 301 vs 308

I've read the 301 and 308 sections of RFC 9110 and the original RFC 7538. RFC 9110's header says it obsoletes RFC 7538, so I'm writing up the answer now.

What they mean. 301 (Moved Permanently) and 308 (Permanent Redirect) both say the target resource has a new permanent URI. Future references should use the new URI, which the server gives in the Location header. The two differ in how they treat the request method.

Method and body handling.

• 301: RFC 9110 says that "For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request." In practice, many clients turn a redirected POST into a GET and drop the body. Servers can't count on the method being preserved.
• 308: The method must not change from POST to GET. RFC 7538 calls it similar to 301, "except that it does not allow changing the request method from POST to GET." A client that follows it should repeat the same method and body at the new URI. This is the point of the code: it is the permanent counterpart of 307, which RFC 9110 says the user agent MUST NOT change the method for. RFC 9110 points to 308 as the fix when the POST-to-GET behavior of 301 is unwanted.
• The RFC text I read doesn't spell out body handling in detail. Resending the body follows from keeping the method, but that is my inference rather than a quoted rule.

Cacheability. Both are heuristically cacheable. That means they can be cached unless the method definition or explicit cache controls say otherwise. RFC 9110 says this about each code. The older RFC 7538 said 308 was "cacheable by default", which is the earlier wording for the same idea.

Where each is specified.

• Both are currently defined in RFC 9110 (HTTP Semantics, 2022): 301 in section 15.4.2 and 308 in section 15.4.9. RFC 9110 obsoletes RFC 7231, which defined 301 before it, and RFC 7538, which first defined 308 as a standards-track document in 2015.
• RFC 7538 itself obsoleted the experimental RFC 7238.

Deployment caveat. 308 is much newer than 301 (June 2014 versus the original HTTP specs). RFC 9110 warns that it "might not be recognized everywhere". RFC 7538 adds that recipients treat unknown 3xx codes like 300 (Multiple Choices), so a client that doesn't know 308 may not redirect automatically. Servers should use 308 only when they trust the client to understand it, or when falling back to 300 behavior is acceptable.

Sources and conflicts. I didn't find any conflict between these sources. The only difference is the cacheability wording, which changed between RFC 7538 and RFC 9110. I tried to open the rfc-editor.org info page for RFC 7538 and got a 404. The obsoletion claim rests on RFC 9110's own header.

{"evidence": [
{"claim": "301 means the target resource has a new permanent URI; 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 a user agent 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", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 means the target resource has a new permanent URI", "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", "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": "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", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "308 may not be recognized everywhere; unknown 3xx codes are treated like 300", "quote": "Section 6 of [RFC7231] requires recipients to treat unknown 3xx status codes the same way as status code 300 (Multiple Choices)", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "RFC 9110 obsoletes RFC 7538 (and 7231), so it is the current specification for 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": "307, the temporary counterpart, 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"},
{"claim": "RFC 7538 added 308 as the missing permanent variant of 307 and obsoleted 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"}
]}