Orchestrator-workers on HTTP 301 vs 308

HTTP 301 vs 308: both permanent, but only 308 keeps the method

What each code means

Both codes mean the same thing: the resource has moved for good. RFC 9110 (HTTP Semantics) defines both with the same sentence: 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). MDN describes both as a permanent move to the URL in the Location header (https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301, https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308). The only real difference is how the client must re-send the request.

How the client treats the method and body

General rule. RFC 9110 says that when following a redirect, the user agent re-sends the original request. It changes the method only "according to the redirecting status code's semantics, if applicable." If the method has been changed to GET or HEAD, it removes content-specific header fields such as Content-Type and Content-Length. In practice that means the body is dropped (https://www.rfc-editor.org/rfc/rfc9110.html).

301. "For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request" (https://www.rfc-editor.org/rfc/rfc9110.html).

• RFC 9110 explains the history. HTTP/1.0 meant 301 and 302 to keep the method, but browsers converged on switching to GET.
• So 301 and 302 "have been adjusted to allow a POST request to be redirected as GET."
• RFC 7231, the previous spec, said the same. It made this rewriting conformant because most user agents did it (https://www.rfc-editor.org/rfc/rfc7231.html).
• MDN's 301 page says the Fetch Standard uses GET after a 301 response to a POST, "as permitted by the HTTP specification" (https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301).
• Result: a POST that gets a 301 may be re-sent as a GET with no body.

308. The client must keep both the method and the body.

• RFC 9110 says 307 and 308 were added "to unambiguously indicate method-preserving redirects" (https://www.rfc-editor.org/rfc/rfc9110.html).
• RFC 7538 says 308 is like 301 "except that it does not allow changing the request method from POST to GET" (https://www.rfc-editor.org/rfc/rfc7538.html).
• MDN says the method and body "will not be modified by the client in the redirected request" (https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308).
• One gap: RFC 9110's own 308 section (15.4.9) does not state the method rule outright. It is implied by the 15.4 introduction and by the 301 section, which points to 308 for cases where the method change is unwanted.

A source conflict. MDN's 308 page says that "A 301 Moved Permanently requires the request method and the body to remain unchanged," and calls switching to GET something "incorrectly handled by older clients" (https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308). This contradicts:

• RFC 9110 and RFC 7231, which both explicitly allow POST to become GET on a 301.
• MDN's own 301 page.

The RFC text is the normative spec, so the MDN 308 page's statement about 301 should be treated as inaccurate.

Compatibility note. 308 is "much younger (June 2014) than its sibling codes and thus might not be recognized everywhere" (https://www.rfc-editor.org/rfc/rfc9110.html). RFC 7538 warns that servers cannot rely on automatic redirection by clients that don't recognize 308 (https://www.rfc-editor.org/rfc/rfc7538.html).

Cacheability

Both codes are cacheable by default. The wording has changed between spec versions:

• RFC 9110 calls both "heuristically cacheable" unless the method definition or explicit cache controls say otherwise. Its section 15.1 lists 301 and 308 among the heuristically cacheable codes (https://www.rfc-editor.org/rfc/rfc9110.html).
• Older specs said "cacheable by default": RFC 7231 for 301 (https://www.rfc-editor.org/rfc/rfc7231.html) and RFC 7538 for 308 (https://www.rfc-editor.org/rfc/rfc7538.html).
• MDN does not address default cacheability on either page.

Where each is specified

Today. Both codes are defined in RFC 9110, HTTP Semantics: 301 in section 15.4.2 and 308 in section 15.4.9 (https://www.rfc-editor.org/rfc/rfc9110.html). MDN also cites "HTTP Semantics" for both.

History.

• 301: Previously defined in RFC 7231 §6.4.2, published in June 2014, which obsoleted RFC 2616 (https://www.rfc-editor.org/rfc/rfc7231.html).
• 308: First defined in the Experimental RFC 7238. It was then re-published with "no technical changes" as Standards Track RFC 7538 in April 2015 (https://www.rfc-editor.org/rfc/rfc7538.html). RFC 9110 cites RFC 7538 as the origin of 308.

Not verified.

• Neither of the rfc-editor pages that were opened (RFC 7231 and RFC 7538) showed an "Obsoleted by RFC 9110" line. So I can't confirm from a retrieved source that they are formally obsoleted.
• The IANA HTTP Status Code Registry returned 404 at every URL tried, so its current references for 301 and 308 were not checked.

{"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 meaning: a new permanent URI for the target resource.", "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": "For 301, a user agent may change POST to GET for the redirected request.", "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 as method-preserving redirects, while 301 and 302 were adjusted to allow POST to become 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 following a redirect, the method changes only if the status code's semantics allow it.", "quote": "Change the request method according to the redirecting status code's semantics, if applicable.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "If the method was changed 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 but does not allow changing POST to GET.", "quote": "Note: This status code is similar to 301 (Moved Permanently)\n      ([RFC7231], Section 6.4.2), except that it does not allow changing\n      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.", "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/Status/308"},
{"claim": "MDN's 301 page says browsers switch POST to GET on 301, as permitted by the HTTP spec.", "quote": "Note: 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/Status/301"},
{"claim": "Conflicting source: MDN's 308 page claims 301 requires the method and body to stay unchanged, contrary to the RFCs and MDN's 301 page.", "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/Status/308"},
{"claim": "RFC 7231 made POST-to-GET rewriting for 301/302 conformant because most user agents do it.", "quote": "Over 10 years later, most user agents still do method\n      rewriting for 301 and 302; therefore, this specification makes\n      that behavior conformant when the original request is POST.", "url": "https://www.rfc-editor.org/rfc/rfc7231.html"},
{"claim": "Under RFC 9110, 301 is heuristically cacheable by default.", "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": "Under RFC 9110, 308 is heuristically cacheable by default.", "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 section 15.1 lists 301 and 308 among the heuristically cacheable 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) can be reused by a cache with heuristic expiration unless otherwise indicated by the method definition or explicit cache controls [CACHING]; all other status codes are not heuristically cacheable.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "The earlier spec RFC 7231 described 301 as cacheable by default.", "quote": "A 301 response is cacheable by default; i.e., unless otherwise\n   indicated by the method definition or explicit cache controls (see\n   Section 4.2.2 of [RFC7234]).", "url": "https://www.rfc-editor.org/rfc/rfc7231.html"},
{"claim": "RFC 7538 described 308 as cacheable by default.", "quote": "A 308 response is cacheable by default; i.e., unless otherwise\n   indicated by the method definition or explicit cache controls (see\n   [RFC7234], Section 4.2.2).", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "RFC 7538 re-published 308 from the Experimental RFC 7238 with no technical changes.", "quote": "This specification contains no technical changes from the\n   Experimental RFC 7238, which it obsoletes.", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "RFC 7231 defined no permanent method-preserving redirect itself and pointed to RFC 7238 for 308.", "quote": "This\n      specification defines no equivalent counterpart for 301 (Moved\n      Permanently) ([RFC7238], however, defines the status code 308\n      (Permanent Redirect) for this purpose).", "url": "https://www.rfc-editor.org/rfc/rfc7231.html"},
{"claim": "308 is newer and may not be recognized everywhere.", "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": "Servers cannot rely on automatic redirection by clients that don't recognize 308.", "quote": "Thus, servers will not be able to rely\n   on automatic redirection happening similar to status codes 301, 302,\n   or 307.", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"}
]}