Orchestrator-workers on HTTP 301 vs 308

HTTP 301 vs 308

Short answer

Both 301 and 308 say that a resource has moved to a new permanent URI, and both are heuristically cacheable. They differ in what the client may do with the request method:

• 301: for historical reasons, the client is allowed to turn a POST into a GET when it follows the redirect.
• 308: the client keeps the same method, and in practice the same body.

Both are now defined in RFC 9110 (HTTP Semantics).

What each code means

301 Moved Permanently. The resource now has a new permanent URI, and future references should use it (https://www.rfc-editor.org/rfc/rfc9110.html, §15.4.2). The server SHOULD send a Location header with the preferred new URI, and the user agent MAY follow it automatically.

308 Permanent Redirect. RFC 9110 §15.4.9 uses almost the same wording: the resource has a new permanent URI that future references should use. It has the same SHOULD rule for the Location header (https://www.rfc-editor.org/rfc/rfc9110.html). RFC 7538, which created 308, describes it as the missing permanent counterpart of 307. It is similar to 301 "except that it does not allow changing the request method from POST to GET" (https://www.rfc-editor.org/rfc/rfc7538.html).

Request method and body

General rule. When a user agent follows a redirect automatically, it SHOULD resend the original request with a defined list of changes. One of those changes applies only "If the request method has been changed to GET or HEAD": the client then removes content-specific headers such as Content-Type and Content-Length (https://www.rfc-editor.org/rfc/rfc9110.html).

301. RFC 9110 says that, for historical reasons, a user agent MAY change the method from POST to GET for the follow-up request. If that is not wanted, the server should send 308 instead (https://www.rfc-editor.org/rfc/rfc9110.html). The RFC's history note explains the split:

• 307 and 308 were added to clearly mark redirects that keep the method.
• 301 and 302 were adjusted to allow POST to be redirected as GET.

MDN notes that the Fetch Standard, which governs browsers, does use GET after a 301 to a POST, "as permitted by the HTTP specification" (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/301). The Fetch Standard itself was not opened, so this point rests on MDN.

308. The method is preserved. RFC 7538 says 308 does not allow the POST-to-GET change (https://www.rfc-editor.org/rfc/rfc7538.html). RFC 9110 classes 308 as "method-preserving" in its §15.4 note. Its §15.4.9 does not contain a "MUST NOT change the method" sentence; that wording appears in the 307 section.

The request body.

• MDN states that with 308 "the request method and the body will not be modified" (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/308).
• In the RFCs, the body consequence is an inference. Body-related headers are stripped only when the method becomes GET or HEAD. Under 308 the request is resent with the body. Under 301, a POST that becomes GET drops its body. Neither the RFC 9110 301 section nor the 308 section says this about the body in so many words.

Sources disagree here. MDN's 308 page says a 301 "requires the request method and the body to remain unchanged" and calls POST-to-GET "incorrectly handled by older clients" (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/308). That contradicts RFC 9110, which explicitly permits the change (MAY). It also contradicts MDN's own 301 page, which calls the change "permitted by the HTTP specification." RFC 9110 is the authoritative source.

Caching

RFC 9110 §15.1 lists both 301 and 308 among the heuristically cacheable status codes (https://www.rfc-editor.org/rfc/rfc9110.html). Each code's own section repeats this. Such a response can be stored and reused unless the method definition or explicit cache controls say otherwise.

RFC 9111 (HTTP Caching) explains what "heuristically cacheable" means in practice (https://www.rfc-editor.org/rfc/rfc9111.html):

• If the server gives no explicit expiration time, a cache MAY estimate one, for example from Last-Modified. A typical fraction is about 10% of the time since that date.
• A cache MUST NOT use such an estimate when an explicit expiration time is present.

So an explicit Cache-Control directive overrides the default. MDN's example 301 response sends cache-control: max-age=2592000,public.

RFC 7538 described 308 as "cacheable by default" (https://www.rfc-editor.org/rfc/rfc7538.html). This is not a conflict. RFC 9111 notes that older specifications used "cacheable by default" for what is now called "heuristically cacheable." RFC 9111 is the current caching specification and obsoletes RFC 7234.

Where each code is specified

Current specification. Both codes are now defined in RFC 9110, HTTP Semantics: 301 in §15.4.2 and 308 in §15.4.9. RFC 9110's header lists the documents it obsoletes, including RFC 7231 and RFC 7538 (https://www.rfc-editor.org/rfc/rfc9110.html).

301 history. The lineage runs RFC 2616 → RFC 7231 → RFC 9110. RFC 7231 (§6.4.2) obsoleted RFC 2616 (https://www.rfc-editor.org/rfc/rfc7231.html). RFC 9110 does not itself list RFC 2616 as something it obsoletes.

308 history.

• 308 was first published in the Experimental RFC 7238.
• RFC 7538, a Standards Track document, replaced RFC 7238 "with no technical changes" (https://www.rfc-editor.org/rfc/rfc7538.html).
• RFC 9110 then obsoleted RFC 7538.
• RFC 7238 itself could not be opened (404). Its Experimental status is known only from RFC 7538's own wording.

Deployment note. RFC 9110 says 308 is "much younger (June 2014)" than its sibling codes and "might not be recognized everywhere." RFC 7538 notes that clients that do not know 308 treat it like 300 (Multiple Choices), so servers cannot rely on automatic redirection.

{"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 means the target resource has a new permanent URI that future references should use.", "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 and 308 the server SHOULD send a Location header with the preferred new URI.", "quote": "The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "RFC 9110's 301 section lets a user agent, for historical reasons, change the method (from POST to GET) on the follow-up request.", "quote": "For historical reasons, a user agent MAY change the", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "307 and 308 were added to clearly mark method-preserving redirects.", "quote": "were later added to unambiguously indicate method-preserving", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 is like 301 but 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": "When following a redirect automatically, the user agent SHOULD resend the original request with specified modifications.", "quote": "When automatically following a redirected request, the user agent SHOULD resend the original request message with the following modifications:", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "Body-related headers are stripped only when the method has been changed to GET or HEAD.", "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": "Per MDN, browsers following the Fetch Standard use GET after a 301 to a POST, as the HTTP spec permits.", "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/Reference/Status/301"},
{"claim": "Per MDN, the client does not modify the method or body when following a 308.", "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 308 page claims 301 requires method and body to stay unchanged, which conflicts with RFC 9110 and MDN's own 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/Reference/Status/308"},
{"claim": "301 and 308 are both listed as 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) 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": "A 301 response 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": "A 308 response 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": "A cache may assign a heuristic expiration time when none is specified.", "quote": "Since origin servers do not always provide explicit expiration times, a cache MAY assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other field values (such as the Last-Modified time) to estimate a plausible expiration time.", "url": "https://www.rfc-editor.org/rfc/rfc9111.html"},
{"claim": "Heuristics must not be used when an explicit expiration time is present.", "quote": "A cache MUST NOT use heuristics to determine freshness when an explicit expiration time is present in the stored response.", "url": "https://www.rfc-editor.org/rfc/rfc9111.html"},
{"claim": "RFC 7538 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 [RFC7234], Section 4.2.2).", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "'Cacheable by default' is the older term for 'heuristically cacheable', so the wording difference is not a conflict.", "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 9111 is the current caching spec and obsoletes RFC 7234.", "quote": "This document obsoletes RFC 7234.", "url": "https://www.rfc-editor.org/rfc/rfc9111.html"},
{"claim": "RFC 9110 is the current specification and obsoletes RFC 7231 (old home of 301) and RFC 7538 (old home of 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 7231 had itself obsoleted RFC 2616.", "quote": "Obsoletes: 2616", "url": "https://www.rfc-editor.org/rfc/rfc7231.html"},
{"claim": "RFC 7538 introduced 308 as the missing permanent variant 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": "RFC 7538 replaced the 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 dates from June 2014 and might 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 for 308 with clients that do not know it.", "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"}
]}