Orchestrator-workers on HTTP 301 vs 308

Summary

301 (Moved Permanently) and 308 (Permanent Redirect) both say the resource has permanently moved to a new URI. They differ in how the client may treat the request method on the follow-up request. With 301, a client may historically turn a POST into a GET. With 308, the method and body must not change.

301 Moved Permanently

• Meaning: RFC 9110 says the target resource has a new permanent URI, and future references should use one of the URIs the server sent. The server should send a Location header, and the user agent may use it for automatic redirection.
• Method and body: For historical reasons, a user agent may change the request method from POST to GET on the follow-up request. RFC 9110 says to use 308 if that is undesired. MDN says the Fetch Standard behaves this way in practice. The reports do not show RFC 9110 saying anything about the body on a 301. The body is normally dropped when POST becomes GET, but that is an inference, not something a source stated.
• Cacheability: RFC 9110 says a 301 response is heuristically cacheable. It can be cached without explicit freshness information, unless the method definition or explicit cache controls say otherwise.
• Specification: It is currently in RFC 9110 (HTTP Semantics), section 15.4.2. RFC 9110 obsoletes RFC 7231, which had itself obsoleted RFC 2616. The worker did not open RFC 2616 itself.

308 Permanent Redirect

• Meaning: RFC 9110 gives the same "new permanent URI" meaning as for 301. RFC 7538 introduced 308 because no existing code was a permanent redirect that kept the method. 307 was the temporary equivalent.
• Method and body: RFC 7538 describes 308 as similar to 301 "except that it does not allow changing the request method from POST to GET". MDN says the client will not modify the method or body in the redirected request. The 308 worker took the method rule from RFC 7538 and MDN, not from the 308 text in RFC 9110. The 301 worker read RFC 9110's wording that altering the method after a 308 is prohibited, but only via MDN.
• Cacheability: RFC 9110 says a 308 response is heuristically cacheable, the same as 301. RFC 7538 originally said "cacheable by default". The reports describe this as a wording change, with RFC 9110 recording no changes from RFC 7538 (Appendix B.7).
• Specification: It is currently in RFC 9110, section 15.4.9. It was originally defined in RFC 7538 (April 2015), which replaced the experimental RFC 7238 with no technical changes. RFC 9110 lists RFC 7538 as obsoleted. The fetched RFC 7538 page did not itself show an "Obsoleted by" line, so that conclusion rests on RFC 9110's header. Two workers quoted slightly different forms of that header: one quoted the abstract's "portions of 7230", the other a header listing 7230 outright.
• Compatibility: RFC 9110 warns that 308 is much younger (June 2014) than its sibling codes and might not be recognized everywhere. RFC 7538 explains that unknown 3xx codes are treated like 300, so servers cannot rely on automatic redirection. It restricts 308 to cases where the client is trusted to understand it or a 300 fallback is harmless.

Where the sources disagree

MDN's 308 page says 301 "requires the request method and the body to remain unchanged", and that older clients wrongly switch to GET. RFC 9110's own 301 text explicitly permits the POST-to-GET change. I treat RFC 9110 as authoritative for what the specification allows. MDN describes the intended semantics and real client behavior.

{"evidence": [
{"claim": "301 means the target resource has a new permanent URI and future references should use one of the enclosed URIs", "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": "The user agent may use the Location header value for automatic redirection", "quote": "The user agent MAY use the Location field value for automatic redirection.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "For a 301, a user agent may change POST to GET for historical reasons", "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": "RFC 9110 points to 308 when the method change is undesired", "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": "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 Section 4.2.2 of [CACHING]).", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 is heuristically cacheable under RFC 9110", "quote": "A 308 response is heuristically cacheable; i.e., unless otherwise", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 means a new permanent URI, per the current specification", "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 like 301 except that the method may not be changed 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": "With 308 the client does not modify the method or body", "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 description of 301 differs from RFC 9110: it says the method should stay unchanged but older clients switch to 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": "MDN says altering the method after a 308 is prohibited, so 308 avoids request modification", "quote": "To avoid user agents modifying the request, use 308 Permanent Redirect instead, as altering the method after a 308 response is prohibited.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/301"},
{"claim": "RFC 7538 originally said 308 was cacheable by default", "quote": "A 308 response is cacheable by default; i.e., unless otherwise", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "RFC 7538 had no technical changes from the experimental RFC it replaced", "quote": "This specification contains no technical changes from the", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "RFC 9110 obsoletes 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 7231 obsoleted RFC 2616", "quote": "Obsoletes: 2616", "url": "https://www.rfc-editor.org/rfc/rfc7231.html"},
{"claim": "RFC 9110 records no changes from RFC 7538", "quote": "B.7. Changes from RFC 7538 None.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 is newer than its sibling codes and may 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 restricts 308 use because clients may not understand it", "quote": "Therefore, the use of status code 308 is restricted to cases where", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"}
]}