Propose-select on HTTP 301 vs 308

301 vs. 308

Both codes mean the resource has moved permanently to a new URI. The difference is what the client may do with the request when it follows the redirect:

• 301: a client may turn a POST into a GET and drop the body.
• 308: a client may not. 308 exists as the version of 301 that keeps the method and body.

What each one means

• 301 Moved Permanently (RFC 9110 §15.4.2): 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." The server SHOULD send a Location header with the new URI, and the user agent MAY follow it automatically. https://www.rfc-editor.org/rfc/rfc9110.html
• 308 Permanent Redirect (RFC 9110 §15.4.9): defined in the same words, with the same Location header rules. https://www.rfc-editor.org/rfc/rfc9110.html

Request method and body

• 301: RFC 9110 says that "for historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request." It points to 308 if you don't want that. https://www.rfc-editor.org/rfc/rfc9110.html

  • Why: HTTP/1.0 originally defined 301 and 302 as keeping the method. Early browsers split on this, and "prevailing practice eventually converged on changing the method to GET." 301 and 302 were later adjusted to allow a POST to be redirected as a GET. https://www.rfc-editor.org/rfc/rfc9110.html
  • Browsers: MDN says that under the Fetch Standard, a browser that gets a 301 in reply to a POST uses GET for the next request. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/301 The WHATWG Fetch Standard URL returned a 404, so this point rests on MDN alone.
• 308: RFC 9110 says 307 and 308 "were later added to unambiguously indicate method-preserving redirects." RFC 7538 describes 308 as like 301 "except that it does not allow changing the request method from POST to GET." https://www.rfc-editor.org/rfc/rfc9110.html, https://www.rfc-editor.org/rfc/rfc7538.html

• The body: RFC 9110's general redirect rules cover this. https://www.rfc-editor.org/rfc/rfc9110.html

  • When following a redirect automatically, the client SHOULD resend the original request message to the new URI.
  • It changes the method only as the status code allows.
  • If the method was changed to GET or HEAD, it removes content-specific headers such as Content-Type and Content-Length, so the body is dropped.
  • Result: after a 308, a POST is resent as a POST with its original body. After a 301, the client may send a GET with no body instead.
  • MDN agrees for 308: "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

Where the sources disagree. MDN's 308 page says a 301 "requires the request method and the body to remain unchanged," and calls older clients that switch to GET wrong. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/308 This conflicts with two sources:

• RFC 9110, the current standard, which explicitly allows a 301 to turn POST into GET.
• MDN's own 301 page, cited above.

The MDN 308 wording matches what HTTP/1.0 originally said. RFC 9110 is the binding text and should be followed.

Caching

• Both codes are "heuristically cacheable." A cache may store them and estimate how long they stay fresh, unless the method definition or explicit cache controls say otherwise (RFC 9110 §15.4.2 and §15.4.9). https://www.rfc-editor.org/rfc/rfc9110.html
• RFC 9111 §4.2.2 says a cache may only use this kind of estimate when the response has no explicit expiration time. It also says older specs called such codes "cacheable by default." https://www.rfc-editor.org/rfc/rfc9111.html
• RFC 7538 used that older wording for 308. https://www.rfc-editor.org/rfc/rfc7538.html

Where each is specified now

• Both are defined in RFC 9110, HTTP Semantics (STD 97): 301 in §15.4.2 and 308 in §15.4.9. https://www.rfc-editor.org/rfc/rfc9110.html
• RFC 9110 obsoletes RFC 7231, which previously defined 301, and RFC 7538, which previously defined 308. https://www.rfc-editor.org/rfc/rfc9110.html
• 308 started in the Experimental RFC 7238. It was then published on the Standards Track as RFC 7538 (April 2015), with no technical changes. https://www.rfc-editor.org/rfc/rfc7538.html
• The caching rules are in RFC 9111 §4.2.2. https://www.rfc-editor.org/rfc/rfc9111.html

Support caveat for 308

• RFC 9110 notes that 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 adds that clients treat an unknown 3xx code like 300 (Multiple Choices). So servers can't count on automatic redirection with 308 unless they're confident the client understands it. https://www.rfc-editor.org/rfc/rfc7538.html

Rule of thumb:

• Use 301 for permanent moves of resources that only receive GET or HEAD requests.
• Use 308 when a permanently moved endpoint must keep receiving POST, PUT and similar requests with their bodies.

{"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 as 301.", "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": "With 301, a user agent 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": "Browsers historically converged on changing the method to GET for 301/302.", "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 signal method-preserving redirects, while 301 and 302 were adjusted to allow POST to become GET.", "quote": "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 differs from 301 only in that it forbids 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, the client resends the original request message to the new URI.", "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": "Content headers (and so the body) are removed only if the method was 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": "MDN says that with 308 neither method nor body is modified.", "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": "According to MDN, browsers following the Fetch Standard switch POST to GET after a 301.", "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": "MDN's 308 page says 301 requires the method and body to stay unchanged, 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/Reference/Status/308"},
{"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.", "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 what earlier specs called '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 7231 and RFC 7538, so both codes are now specified in RFC 9110.", "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 made no technical changes from the Experimental RFC 7238.", "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 is newer and may not be recognized by every client.", "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 fall back to 300 semantics, servers cannot rely on automatic redirection with 308 for older 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"}
]}