Propose-select on HTTP 301 vs 308

Difference Between HTTP Status Codes 301 and 308

HTTP status codes 301 (Moved Permanently) and 308 (Permanent Redirect) are both permanent redirect responses, but they differ significantly in how they treat the request method and body when a client follows the redirect.

HTTP 301 (Moved Permanently)

The 301 status code indicates that a requested resource has been permanently moved to a new URI. According to RFC 9110, "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." However, for historical reasons, the HTTP specification permits user agents to change the request method from POST to GET when following a 301 redirect. This behavior was a pragmatic choice to maintain compatibility with older client implementations, even though the original HTTP specification intended the method to remain unchanged. As RFC 9110 explicitly notes, "For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 308 (Permanent Redirect) status code can be used instead." A 301 response is heuristically cacheable, meaning it can be cached by default unless otherwise indicated by explicit cache control headers.

HTTP 308 (Permanent Redirect)

The 308 status code also indicates that a resource has been permanently moved to a new URI. As specified in RFC 9110, "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." The critical difference is that 308 explicitly prohibits clients from changing the request method or body. According to RFC 7538, "This status code is similar to 301 (Moved Permanently), except that it does not allow changing the request method from POST to GET." This was introduced specifically to provide a permanent redirect equivalent that does not allow method conversion. Like 301, a 308 response is also heuristically cacheable.

Request Method and Body Handling

When a client receives a 301 redirect, it may change the request method from POST to GET in the subsequent request (though clients following stricter specifications should preserve the method). This conversion means the original request body is typically discarded. In contrast, when receiving a 308 redirect, the client must preserve both the request method and the request body exactly as originally sent. This makes 308 the appropriate choice when a POST request needs to be redirected to a different URI while maintaining the original operation.

Cacheability

Both 301 and 308 responses are cacheable by default, unless otherwise indicated by cache control directives. This means that clients and intermediate caches may reuse the response without revalidating the redirect mapping with the server, which can improve performance for frequently accessed resources.

Current Specification Status

The 301 status code is specified in RFC 9110 (HTTP Semantics, Section 15.4.2) and was previously defined in RFC 7231 (HTTP/1.1 Semantics and Content, Section 6.4.2). The 308 status code is specified in RFC 9110 (Section 15.4.9) and was initially defined in RFC 7538 (The Hypertext Transfer Protocol Status Code 308 - Permanent Redirect, April 2015), which obsoleted the earlier experimental RFC 7238. RFC 7538 was created to fill a gap in the specification, as RFC 7231 did not define a permanent variant of status code 307.