Plan-execute on HTTP 301 vs 308

301 and 308 mean the same thing: the resource has moved permanently to a new URL. Both are cacheable by default, and both are now defined in RFC 9110. The only difference is that after a 301, a client may turn a POST into a GET, and after a 308 it must resend the original method and body.

What each means. RFC 9110 defines 301 as meaning "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 section uses exactly the same definition. In both cases the server SHOULD send a Location header with the preferred new URI, and the client MAY follow it automatically (https://www.rfc-editor.org/rfc/rfc9110.html).

Method and body.

• 301: The spec lets a client switch from POST to GET: "For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request." It also says 308 can be used if that isn't wanted (https://www.rfc-editor.org/rfc/rfc9110.html).

  • Why: HTTP/1.0 originally defined 301 and 302 as keeping the method. Browsers didn't agree on this, and common practice settled on switching to GET. 307 and 308 were then "added to unambiguously indicate method-preserving redirects" (https://www.rfc-editor.org/rfc/rfc9110.html).
  • The body: when following a redirect, the client changes the method only if the status code's meaning allows it. If the method becomes GET or HEAD, the client removes the content-specific headers such as Content-Type and Content-Length. In practice, the body is dropped (https://www.rfc-editor.org/rfc/rfc9110.html).
  • The switch only applies to POST. Other methods are resent as they were.
• 308: The client must resend the same method and the same body to the new URI. RFC 7538, the RFC that originally defined 308, says it "is similar to 301 (Moved Permanently) ... except that it does not allow changing the request method from POST to GET" (https://www.rfc-editor.org/rfc/rfc7538.html). RFC 9110's own 308 section doesn't repeat that sentence. It gets the same result through the method-preserving note above and its comment under 301 that 308 is the alternative.
• Browsers in practice: MDN says that under the Fetch Standard, a browser that gets a 301 in response to a POST uses GET for the next request. It adds that changing the method after a 308 is not allowed (https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301).

Where the sources disagree. MDN's 308 page says that a 301 "requires the request method and the body to remain unchanged" and that older clients handle this "incorrectly" by switching to GET (https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308). That conflicts with RFC 9110, which explicitly allows the switch, and with MDN's own 301 page, which calls it "permitted by the HTTP specification." The RFC is the authoritative source.

Caching. RFC 9110 calls both codes "heuristically cacheable" and lists 301 and 308 among them (https://www.rfc-editor.org/rfc/rfc9110.html). This means that if a response has no explicit expiry, a cache may guess a lifetime and reuse it. The method definition or explicit cache headers (Cache-Control or Expires) can override this (https://www.rfc-editor.org/rfc/rfc9111.html). RFC 9111 notes that older specifications called this "cacheable by default," which is the wording RFC 7538 used for 308 (https://www.rfc-editor.org/rfc/rfc7538.html).

Where each is specified.

• Current: RFC 9110, HTTP Semantics (June 2022). 301 is in §15.4.2 and 308 in §15.4.9 (https://www.rfc-editor.org/rfc/rfc9110.html).
• 301 history: RFC 9110 replaces RFC 7231, which previously held 301's definition (§6.4.2, as RFC 7538 cites it).
• 308 history: 308 was first published as the Experimental RFC 7238, which RFC 7538 (April 2015, Standards Track) replaced. RFC 9110 in turn obsoletes RFC 7538 (https://www.rfc-editor.org/rfc/rfc7538.html, https://www.rfc-editor.org/rfc/rfc9110.html).
• Compatibility: RFC 9110 notes that 308 is "much younger (June 2014)" than the other redirect codes and so might not be recognised everywhere.

{"evidence": [
{"claim": "301 means the 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 permanent-move meaning.", "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 historical reasons, a client following a 301 may change POST to GET.", "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 to mark method-preserving redirects, and 301/302 were adjusted to allow POST to become GET.", "quote": "Prevailing practice eventually converged on changing the method to GET.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "When following a redirect, the client changes the method only if the status code's meaning allows 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": "308 is like 301 except that changing POST to GET is not allowed.", "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": "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": "\"Heuristically cacheable\" is the newer name for \"cacheable by default\".", "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 9110 obsoletes RFC 7538 (and RFC 7231).", "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 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": "MDN says browsers following the Fetch Standard switch POST to GET after a 301, and that changing the method after a 308 is prohibited.", "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/Status/301"},
{"claim": "MDN's 308 page says 301 requires the method to stay the same, which conflicts with RFC 9110.", "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"}
]}