Plan-execute on HTTP 301 vs 308

Summary. 301 and 308 both mean "this resource has moved permanently." They differ only in what a client may do with the request method and body when it follows the redirect. For 301, a client may turn a POST into a GET. For 308, the method must stay the same.

What each means. RFC 9110 gives 301 and 308 the same core definition. Each says 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." Both say the server SHOULD send a Location header with the preferred new URI, and that the user agent MAY use it for automatic redirection (https://www.rfc-editor.org/rfc/rfc9110.html). Both also say a user agent with link-editing capability can permanently replace references to the old URI, though this is usually ignored unless the client is actively editing content. The sections are 15.4.2 for 301 and 15.4.9 for 308.

Method and body handling.

• 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.

  • The reason is history. In HTTP/1.0, 301 and 302 were method-preserving, but early user agents split on whether to redirect POST as POST or as GET. "Prevailing practice eventually converged on changing the method to GET," so 301 was adjusted to allow that.
  • The generic redirect-following rules in section 15.4 say that if the method has been changed to GET or HEAD, the client should remove content-specific headers such as Content-Type and Content-Length. The request body is effectively dropped in that case.

• 308. It was added so that a permanent redirect could unambiguously keep the method. RFC 7538 says it 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." RFC 9110 describes 307 and 308 as having been "added to unambiguously indicate method-preserving redirects." A client following a 308 therefore resends the same method, and for POST that means the same body, to the new URI.

  • 308's own section in RFC 9110 (15.4.9) does not repeat a "MUST NOT change the method" sentence. By contrast, 307's section does: "the user agent MUST NOT change the request method." For 308, the method-preservation rule comes from RFC 7538 and from the 301 and 15.4 notes in RFC 9110.
  • RFC 7538 also notes that 308 is newer, so servers should use it only where they are confident the client understands it. RFC 9110 has a similar note that it "might not be recognized everywhere."

Caching. Both are cacheable by default. RFC 9110 says "A 301 response is heuristically cacheable" and "A 308 response is heuristically cacheable". In both cases this applies unless the method definition or explicit cache controls say otherwise (it points to Section 4.2.2 of the caching spec, RFC 9111). RFC 7538 used different wording for 308: "cacheable by default." These read as the same idea in different words. I did not open RFC 7231's 301 text to compare it.

Where each is specified.

• Current spec. Both codes are in RFC 9110 (HTTP Semantics, June 2022): 301 in section 15.4.2 and 308 in section 15.4.9.
• Superseded specs. RFC 9110's header lists "Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, 7538, 7615, 7694". RFC 7231 was the older home of 301, and RFC 7538 (April 2015) was the original definition of 308. The RFC 7538 page I opened is the original 2015 text and does not show its later obsolescence. I took that from RFC 9110's header.
• IANA registry. I did not check it.

{"evidence": [
{"claim": "RFC 9110 defines 301 as a permanent move to a new URI, in 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 responses are heuristically cacheable", "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": "RFC 9110 defines 308 as a permanent move to a new URI, in section 15.4.9", "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": "308 responses are heuristically cacheable", "quote": "A 308 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": "History: 301/302 were originally method-preserving, practice converged on GET, and 307/308 were added to unambiguously preserve the method", "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 the method becomes GET or HEAD, content-specific headers are removed from the redirected request", "quote": "If the request method has been changed to GET or HEAD, remove content-specific header fields, including (but not limited to)", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"},
{"claim": "RFC 9110 obsoletes RFC 7231 and RFC 7538, so it is where 301 and 308 are now specified", "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 originally defined 308 as the permanent counterpart of 307, which does not allow POST to become GET", "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 says 308 is like 301 except that it does not allow changing the method from 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 describes 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", "url": "https://www.rfc-editor.org/rfc/rfc7538.html"},
{"claim": "RFC 9110's 307 section explicitly forbids changing the method", "quote": "the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.", "url": "https://www.rfc-editor.org/rfc/rfc9110.html"}
]}