]> The Purpose Declined HTTP Status Code Cloudflare
Melbourne Australia mnot@mnot.net https://mnot.net/
Internet-Draft This specification defines an HTTP status code to indicate that the server is denying a request based upon its declared purpose. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the HTTP Working Group mailing list (), which is archived at . Working Group information can be found at . Source for this draft and an issue tracker can be found at .
Introduction introduces a mechanism whereby HTTP user agents can speculatively request a representation of a resource, in order to improve perceived performance. In some circumstances, a server might have information that leads it to believe that sending a full response will not improve performance, and could have negative impacts. When this happens, it is common practice to use a 503 (Service Unavailable) status code. However, this has been observed to cause confusion: a server operator who sees a spike in that status code being sent tends to draw the conclusion that there is a server-side operational issue. While other status codes (e.g., 403 (Forbidden)) could be used, they can also suffer (to varying degrees) from the same problem: being confused with an error, operational problem, or other condition. This specification defines a new status code to specifically address this situation, making servers' behavior more legible to their operators. It does not introduce any new capability.
Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
The 419 (Purpose Declined) Status Code The 419 (Purpose Declined) status code indicates that the server is refusing a request based upon its declared purpose. A request's declared purpose is indicted by its Sec-Purpose header field . This indication is only applicable to the associated request; future requests with the same purpose might or might not succeed. Because responses with this status code are not intended to be displayed to a user, they SHOULD have zero-length content, and any content that is sent SHOULD be discarded. Both origin servers and gateways acting on their behalf (e.g., Content Delivery Networks and so-called "reverse proxies") MAY generate this status code. Proxies (who are not acting on behalf of the origin server) SHOULD NOT generate it. This status code is not heuristically cacheable (see ). To avoid responses with this status code being reused by a cache, they SHOULD NOT be cacheable (see ).
IANA Considerations The following entry should be registered in the "HTTP Status Codes" registry:
  • Code: 419
  • Description: Purpose Declined
  • Specification: RFC nnnn (this document)
Security Considerations The security considerations of and apply. Conceivably, the use of this status code could leak information about the internal state of the server; caution should be exercised to assure that it does not.
Normative References HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. HTTP Caching The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. Fetch WHAT Working Group n.d. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.