Orchestrator-workers on HTTP 301 vs 308

Short answer: 301 and 308 both mean "this resource has moved permanently." They differ in how a client must treat the request method. A client following a 301 may turn a POST into a GET, which drops the body. A client following a 308 must keep the method and body unchanged.

What each means. RFC 9110 defines both codes in nearly identical terms: the target resource has been assigned a new permanent URI, and future references ought to use it. For 301 the text is "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." (https://www.rfc-editor.org/rfc/rfc9110.html). The 308 text is the same with "308 (Permanent Redirect)". For both, the server should send a Location header, and "The user agent MAY use the Location field value for automatic redirection." (https://www.rfc-editor.org/rfc/rfc9110.html)

Method and body handling.

• 301: The method can change. RFC 9110 says: "For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request." It adds that if this is undesired, 308 can be used instead (https://www.rfc-editor.org/rfc/rfc9110.html).

  • The history: HTTP/1.0 clients were split on whether to resend POST as POST. RFC 9110 says "Prevailing practice eventually converged on changing the method to GET." (https://www.rfc-editor.org/rfc/rfc9110.html)
  • The workers reported that, per RFC 9110, a client that changes the method to GET or HEAD also removes content-specific headers such as Content-Type and Content-Length.
  • Dropping the body on a POST→GET switch follows from GET carrying no body. That is an inference, not a quoted statement.
  • Browsers follow the Fetch Standard. MDN says that on a 301 to a POST, "it uses the GET method in the subsequent redirection request, as permitted by the HTTP specification." (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/301)

• 308: RFC 7538 describes it as "similar to 301 (Moved Permanently) ([RFC7231], Section 6.4.2), except that it does not allow changing the request method from POST to GET." (https://www.rfc-editor.org/rfc/rfc7538.html)

  • MDN states the consequence directly: "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)
  • RFC 9110's own §15.4.9 text for 308 does not contain a "MUST NOT change the method" sentence. In RFC 9110 the rule is implied by the 301 note and by §15.4's remark that 307 and 308 "were later added to unambiguously indicate method-preserving redirects". The workers found that RFC 9110 states "MUST NOT" outright only for 307.
• Why 308 exists: 307 was the method-preserving temporary redirect, and there was no permanent equivalent. RFC 7538 says: "Section 6.4.7 of [RFC7231] states that it does not define a permanent variant of status code 307; this specification adds the status code 308, defining this missing variant (Section 3)." (https://www.rfc-editor.org/rfc/rfc7538.html) This gives the pairs 301↔308 (permanent) and 302↔307 (temporary), where the only difference within a pair is whether POST→GET rewriting is allowed.

Cacheability. Both are cacheable in the same way. RFC 9110 says: "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])." The 308 section uses the identical sentence (https://www.rfc-editor.org/rfc/rfc9110.html). RFC 9110 §15.1 lists both among the heuristically cacheable codes: "200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, and 501". Explicit cache headers still apply. The older documents used different wording, "cacheable by default" (RFC 7231 for 301, https://www.rfc-editor.org/rfc/rfc7231.html; RFC 7538 for 308, https://www.rfc-editor.org/rfc/rfc7538.html). RFC 9111 notes that this is a rename, not a change: "Note that in previous specifications, heuristically cacheable response status codes were called \"cacheable by default\"." (https://www.rfc-editor.org/rfc/rfc9111.html)

Where each is specified.

• Current: both are in RFC 9110 (HTTP Semantics), 301 in §15.4.2 and 308 in §15.4.9. Its header says it "obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230." (https://www.rfc-editor.org/rfc/rfc9110.html) Caching rules are in RFC 9111.
• Earlier: 301 was defined in RFC 7231 §6.4.2. RFC 7231 traces it to HTTP/1.0 (RFC 1945). 308 was defined in RFC 7538 (April 2015), which states it "contains no technical changes from the Experimental RFC 7238, which it obsoletes" (https://www.rfc-editor.org/rfc/rfc7538.html). RFC 7231 and RFC 7538 are both now obsoleted by RFC 9110.
• Unverified: the RFC 7538 page I was given shows only "Obsoletes: 7238", so its obsolete status rests on RFC 9110's header. No worker could open RFC 2616, so I make no claim about it.

Client support caveat. 308 is the newer code. RFC 9110 says it "is much younger (June 2014) than its sibling codes and thus might not be recognized everywhere." RFC 7538 §4 explains that unknown 3xx codes are treated like 300, so "servers will not be able to rely on automatic redirection". It restricts 308 to cases where the server trusts the client to understand it, or where falling back to 300 is harmless. The workers did not check browser-compatibility data, so I cannot give version-by-version support.

Source disagreement. MDN's 308 page says a 301 "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." That conflicts with RFC 9110, which explicitly permits POST→GET on a 301. MDN's own 301 page agrees with RFC 9110. I follow RFC 9110 as the authoritative specification and treat the MDN 308 wording as imprecise.

{"evidence": [
{"claim": "RFC 9110 defines 301 as a permanent reassignment of the target resource to a new 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": "RFC 9110 defines 308 in the same permanent-move terms", "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": "The user agent may follow the Location header automatically", "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 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. 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": "Historically clients were split and practice converged on changing the method to GET", "quote": "Prevailing practice eventually converged on changing the method to GET.", "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 were adjusted to allow POST to 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": "308 is like 301 except that it does not allow changing POST to GET", "quote": "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": "308 was created to supply the missing permanent counterpart of 307", "quote": "Section 6.4.7 of [RFC7231] states that it does not define a permanent variant of status code 307; this specification adds the status code 308, defining this missing variant (Section 3).", "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": "Browsers following the Fetch Standard switch to GET after a 301 to a POST", "quote": "In the Fetch Standard, when a user agent receives a 301 in response to a POST request, it uses the GET method in the subsequent redirection request, as permitted by the HTTP specification.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/301"},
{"claim": "RFC 9110 says 301 is heuristically cacheable (308 has the identical sentence)", "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": "RFC 9110 says 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 Section 4.2.2 of [CACHING]).", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "RFC 9110 lists both 301 and 308 among heuristically cacheable status codes", "quote": "Responses with status codes that are defined as heuristically cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, and 501 in this specification)", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "The older term 'cacheable by default' was renamed 'heuristically cacheable'", "quote": "Note that in previous specifications, heuristically cacheable response status codes were called \"cacheable by default\".", "url": "https://www.rfc-editor.org/rfc/rfc9111.html"},
{"claim": "RFC 7231 originally specified 301 with 'cacheable by default' wording", "quote": "A 301 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).", "url": "https://www.rfc-editor.org/rfc/rfc7231.html"},
{"claim": "RFC 7538 originally specified 308 with 'cacheable by default' wording", "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 (301) and RFC 7538 (308)", "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 originally defined 308 and obsoleted experimental RFC 7238 without 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": "308 may not be recognized by older clients", "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"},
{"claim": "Because unknown 3xx codes are treated as 300, servers cannot rely on automatic redirection for 308 with old clients", "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's 308 page says 301 requires method preservation, which conflicts with RFC 9110's permission to change POST 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"}
]}