HTTP status codes convey semantics both for the benefit of generic HTTP components -- such as caches, intermediaries, and clients -- and applications themselves. However, applications can encounter a number of pitfalls in their use.¶
First, status codes are often generated by components other than the application itself. This can happen, for example, when network errors are encountered; when a captive portal, proxy, or content delivery network is present; or when a server is overloaded or thinks it is under attack. They can even be generated by generic client software when certain error conditions are encountered. As a result, if an application assigns specific semantics to one of these status codes, a client can be misled about its state because the status code was generated by a generic component, not the application itself.¶
Furthermore, mapping application errors to individual HTTP status codes one-to-one often leads to a situation where the finite space of applicable HTTP status codes is exhausted. This, in turn, leads to a number of bad practices -- including minting new, application-specific status codes or using existing status codes even though the link between their semantics and the application's is tenuous at best.¶
Instead, applications using HTTP should define their errors to use the most applicable status code, making generous use of the general status codes (200, 400, and 500) when in doubt. Importantly, they should not specify a one-to-one relationship between status codes and application errors, thereby avoiding the exhaustion issue outlined above.¶
To distinguish between multiple error conditions that are mapped to the same status code and to avoid the misattribution issue outlined above, applications using HTTP should convey finer-grained error information in the response's message content and/or header fields. [PROBLEM-DETAILS] provides one way to do so.¶
Because the set of registered HTTP status codes can expand, applications using HTTP should explicitly point out that clients ought to be able to handle all applicable status codes gracefully (i.e., falling back to the generic n00 semantics of a given status code; e.g., 499 can be safely handled as 400 (Bad Request) by clients that don't recognise it). This is preferable to creating a "laundry list" of potential status codes since such a list won't be complete in the foreseeable future.¶
Applications using HTTP MUST NOT re-specify the semantics of HTTP status codes, even if it is only by copying their definition. It is NOT RECOMMENDED they require specific reason phrases to be used; the reason phrase has no function in HTTP, is not guaranteed to be preserved by implementations, and is not carried at all in the HTTP/2 [HTTP/2] message format.¶
Applications MUST only use registered HTTP status codes. As with methods, new HTTP status codes are rare and required (by [HTTP]) to be registered with IETF Review. Similarly, HTTP status codes are generic; they are required (by [HTTP]) to be potentially applicable to all resources, not just to those of one application.¶
When authors believe that a new status code is required, they are encouraged to engage with the HTTP community early (e.g., on the <mailto:ietf-http-wg@w3.org> mailing list) and document their proposal as a separate HTTP extension, rather than as part of an application's specification.¶
The 3xx series of status codes specified in Section 15.4 of [HTTP] directs the user agent to another resource to satisfy the request. The most common of these are 301, 302, 307, and 308, all of which use the Location response header field to indicate where the client should resend the request.¶
There are two ways that the members of this group of status codes differ:¶
- Whether they are permanent or temporary. Permanent redirects can be used to update links stored in the client (e.g., bookmarks), whereas temporary ones cannot. Note that this has no effect on HTTP caching; it is completely separate.¶
- Whether they allow the redirected request to change the request method from POST to GET. Web browsers generally do change POST to GET for 301 and 302; therefore, 308 and 307 were created to allow redirection without changing the method.¶
This table summarises their relationships:¶
Table 1
|
Permanent |
Temporary |
Allows change of the request method from POST to GET |
301 |
302 |
Does not allow change of the request method |
308 |
307 |
The 303 (See Other) status code can be used to inform the client that the result of an operation is available at a different location using GET.¶
As noted in [HTTP], a user agent is allowed to automatically follow a 3xx redirect that has a Location response header field, even if they don't understand the semantics of the specific status code. However, they aren't required to do so; therefore, if an application using HTTP desires redirects to be automatically followed, it needs to explicitly specify the circumstances when this is required.¶
Redirects can be cached (when appropriate cache directives are present), but beyond that, they are not "sticky" -- i.e., redirection of a URI will not result in the client assuming that similar URIs (e.g., with different query parameters) will also be redirected.¶
Applications using HTTP are encouraged to specify that 301 and 302 responses change the subsequent request method from POST (but no other method) to GET to be compatible with browsers.
Generally, when a redirected request is made, its header fields are copied from the original request. However, they can be modified by various mechanisms; e.g., sent Authorization ([HTTP], Section 11) and Cookie ([COOKIES]) header fields will change if the origin (and sometimes path) of the request changes. An application using HTTP should specify if any request header fields that it defines need to be modified or removed upon a redirect; however, this behaviour cannot be relied upon since a generic client (like a browser) will be unaware of such requirements.¶