Plan-execute-verify on HTTP 301 vs 308

Short version: 301 and 308 both mean "this resource has moved permanently." They differ in how the client re-sends the request. With 301, a client may turn a POST into a GET. With 308, the method must stay the same. Both are now specified in RFC 9110.

What each code means

• RFC 9110 defines both codes in nearly identical words. 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 (Permanent Redirect) text in Section 15.4.9 of the same RFC uses the same sentence. For both codes the server SHOULD send a Location header, and the user agent MAY follow it automatically.

Request method and body

• 301: 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).

  • In practice many clients rewrite POST to GET on a 301. RFC 9110 explains that 301 and 302 were originally method-preserving in HTTP/1.0, but early user agents split on whether to redirect POST as POST or as GET. Practice converged on GET, and 301 and 302 "have been adjusted to allow a POST request to be redirected as GET" (https://www.rfc-editor.org/rfc/rfc9110.html).

• 308: RFC 7538, the original 308 specification, describes it as 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).

  • RFC 9110 says 307 and 308 "were later added to unambiguously indicate method-preserving redirects" (https://www.rfc-editor.org/rfc/rfc9110.html).
  • One caveat: the 308 section of RFC 9110 has no explicit "MUST NOT change the method" sentence, unlike its 307 section. The rule comes from the general redirect procedure and the note above.

• Body: RFC 9110's general redirect rules say the client should resend the original request with modifications, including changing the method "according to the redirecting status code's semantics". They also say that if the method became GET or HEAD, content-specific headers such as Content-Type and Content-Length are removed (https://www.rfc-editor.org/rfc/rfc9110.html). In practice, then:

  • after a 308, the same method and body are resent;
  • after a 301 that a client turns into GET, the body is dropped.
  • MDN's 308 page agrees on 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 sources disagree: MDN's same page also says 301 "requires the request method and the body to remain unchanged … but this is incorrectly handled by older clients." That does not match RFC 9110 and RFC 7231, which explicitly permit POST→GET on 301. I am following the RFCs. The MDN wording appears to describe the original HTTP/1.0 intent.

Cacheability

• 301: RFC 9110 says "A 301 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls". RFC 7231 used the older wording "cacheable by default" (https://www.rfc-editor.org/rfc/rfc7231.html).
• 308: RFC 9110 uses the same "heuristically cacheable" sentence for 308 (https://www.rfc-editor.org/rfc/rfc9110.html). RFC 7538 said "A 308 response is cacheable by default" (https://www.rfc-editor.org/rfc/rfc7538.html).
• So both are cacheable by default. Explicit cache controls can override this.

Where each is specified

• Current: both codes are in RFC 9110 (HTTP Semantics): 301 in Section 15.4.2 and 308 in Section 15.4.9. Its header says it "obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230." RFC 9110 also lists 301 and 308 in its IANA status-code table, Section 18.3 (https://www.rfc-editor.org/rfc/rfc9110.html).

• Historical:

  • 301 was previously in RFC 7231, Section 6.4.2. That text pointed to 307 as the way to avoid the POST→GET change, because 308 did not yet exist in the HTTP semantics RFC (https://www.rfc-editor.org/rfc/rfc7231.html).
  • 308 was originally defined in RFC 7538, which says it "contains no technical changes from the Experimental RFC 7238" (https://www.rfc-editor.org/rfc/rfc7538.html).
• Deployment: RFC 9110 notes that 308 is much younger than its sibling codes and so "might not be recognized everywhere." Its pointer to RFC 7538 Section 4 is the source for this caution.

Gaps

• I could not open the IANA registry page (it returned 404). I therefore could not check what it lists for 301 and 308, and I am relying on RFC 9110's own registration table instead.
• The RFC 7538 page I opened shows no "obsoleted by" banner. The obsoletion claim comes from RFC 9110's header.

{"evidence": [
{"claim": "301 means the resource has a new permanent URI (RFC 9110, Section 15.4.2)", "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": "For 301, a user agent may change POST to GET, and 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.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "301 is heuristically cacheable in RFC 9110", "quote": "A 301 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "308 is heuristically cacheable in RFC 9110", "quote": "A 308 response is heuristically cacheable; i.e., unless otherwise", "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 be redirected as 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 a redirect changes the method to GET or HEAD, content-specific headers are removed (body handling)", "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,", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "RFC 9110 obsoletes RFC 7231 and RFC 7538, so it is the current specification for both codes", "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 9110's IANA registration table lists 308 Permanent Redirect at Section 15.4.9", "quote": "| 308   | Permanent Redirect            | 15.4.9  |", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "RFC 9110 warns that 308 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": "RFC 7538 originally defined 308 as like 301 but not allowing POST to GET", "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": "RFC 7538 said 308 is cacheable by default", "quote": "A 308 response is cacheable by default; i.e., unless otherwise", "url": "https://www.rfc-editor.org/rfc/rfc7538.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": "RFC 7231 previously specified 301, including the POST-to-GET allowance and cacheability by default", "quote": "A 301 response is cacheable by default; i.e., unless otherwise", "url": "https://www.rfc-editor.org/rfc/rfc7231.html"},
{"claim": "MDN says 308 keeps method and body unchanged, and describes 301 differently from the RFCs", "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"}
]}