]>

Prahran Australia mnot@mnot.net https://www.mnot.net/

erik.wilde@dret.net http://dret.net/netdret/

United States of America sanjay.dalal@cal.berkeley.edu https://github.com/sdatspun2

Applications and Real-Time HTTPAPI status HTTP error problem API JSON XML This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content and/or fields to avoid the need to define new error response formats for HTTP APIs. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction HTTP status codes () cannot always convey enough information about errors to be helpful. While humans using Web browsers can often understand an HTML response body, non-human consumers of HTTP APIs have difficulty doing so. To address that shortcoming, this specification defines simple JSON and XML document formats and a HTTP field to describe the specifics of problem(s) encountered -- "problem details". For example, consider a response indicating that the client's account doesn't have enough credit. The API's designer might decide to use the 403 Forbidden status code to inform HTTP-generic software (such as client libraries, caches, and proxies) of the response's general semantics. API-specific problem details (such as the why the server refused the request and the applicable account balance) can be carried in the response content, so that the client can act upon them appropriately (for example, triggering a transfer of more credit into the account). This specification identifies the specific "problem type" (e.g., "out of credit") with a URI . HTTP APIs can use URIs under their control to identify problems specific to them, or can reuse existing ones to facilitate interoperability and leverage common semantics (see ). Problem details can contain other information, such as a URI identifying the problem's specific occurrence (effectively giving an identifier to the concept "The time Joe didn't have enough credit last Thursday"), which can be useful for support or forensic purposes. The data model for problem details is a JSON object; when serialized as a JSON document, it uses the "application/problem+json" media type. defines an equivalent XML format, which uses the "application/problem+xml" media type. Note that problem details are (naturally) not the only way to convey the details of a problem in HTTP. If the response is still a representation of a resource, for example, it's often preferable to describe the relevant details in that application's format. Likewise, defined HTTP status codes cover many situations with no need to convey extra detail. This specification's aim is to define common error formats for applications that need one so that they aren't required to define their own, or worse, tempted to redefine the semantics of existing HTTP status codes. Even if an application chooses not to use it to convey errors, reviewing its design can help guide the design decisions faced when conveying errors in an existing format.

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. This document uses the following terminology from to specify syntax and parsing: Dictionary, String, and Integer.

The Problem Details JSON Object The canonical model for problem details is a JSON object. When serialized in a JSON document, that format is identified with the "application/problem+json" media type. For example: Here, the out-of-credit problem (identified by its type) indicates the reason for the 403 in "title", identifies the specific problem occurrence with "instance", gives occurrence-specific details in "detail", and adds two extensions: "balance" conveys the account's balance, and "accounts" lists links where the account can be topped up. When designed to accommodate it, problem-specific extensions can allow more than one instance of the same problem type to be conveyed. For example: The fictional problem type here defines the "errors" extension, an array that describes the details of each validation error. Each member is an object containing "detail" to describe the issue, and "pointer" to locate the problem within the request's content using a JSON Pointer . When an API encounters multiple problems that do not share the same type, it is RECOMMENDED that the most relevant or urgent problem be represented in the response. While it is possible to create generic "batch" problem types that convey multiple, disparate types, they do not map well into HTTP semantics. Note also that the API has responded with the application/problem+json type, even though the client did not list it in Accept, as is allowed by HTTP (see ).

Members of a Problem Details Object Problem detail objects can have the following members. If a member's value type does not match the specified type, the member MUST be ignored -- i.e., processing will continue as if the member had not been present.

"type" The "type" member is a JSON string containing a URI reference that identifies the problem type. Consumers MUST use the "type" URI (after resolution, if necessary) problem's primary identifier. When this member is not present, its value is assumed to be "about:blank". If the type URI is a locator (e.g., those with a "http" or "https" scheme), dereferencing it SHOULD provide human-readable documentation for the problem type (e.g., using HTML ). However, consumers SHOULD NOT automatically dereference the type URI, unless they do so when providing information to developers (e.g., when a debugging tool is in use). When "type" contains a relative URI, it is resolved relative to the document's base URI, as per . However, using relative URIs can cause confusion, and they might not be handled correctly by all implementations. For example, if the two resources "https://api.example.org/foo/bar/123" and "https://api.example.org/widget/456" both respond with a "type" equal to the relative URI reference "example-problem", when resolved they will identify different resources ("https://api.example.org/foo/bar/example-problem" and "https://api.example.org/widget/example-problem" respectively). As a result, it is RECOMMENDED that absolute URIs be used in "type" when possible, and that when relative URIs are used, they include the full path (e.g., "/types/123"). The type URI can also be a non-resolvable URI. For example, the tag URI scheme can be used to uniquely identify problem types: Non-resolvable URIs ought not be used when there is some future possibility that it might become desirable to do so. For example, if an API designer used the URI above and later adopted a tool that resolves type URIs to discover information about the error, taking advantage of that capability would require switching to a resolvable URI, creating a new identity for the problem type and thus introducing a breaking change.

"status" The "status" member is a JSON number indicating the HTTP status code () generated by the origin server for this occurrence of the problem. The "status" member, if present, is only advisory; it conveys the HTTP status code used for the convenience of the consumer. Generators MUST use the same status code in the actual HTTP response, to assure that generic HTTP software that does not understand this format still behaves correctly. See for further caveats regarding its use. Consumers can use the status member to determine what the original status code used by the generator was, in cases where it has been changed (e.g., by an intermediary or cache), and when message bodies persist without HTTP information. Generic HTTP software will still use the HTTP status code.

"title" The "title" member is a JSON string containing a short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for localization (e.g., using proactive content negotiation; see ). The "title" string is advisory and included only for users who are not aware of the semantics of the URI and can not discover them (e.g., during offline log analysis).

"detail" The "detail" member is a JSON string containing a human-readable explanation specific to this occurrence of the problem. The "detail" member, if present, ought to focus on helping the client correct the problem, rather than giving debugging information. Consumers SHOULD NOT parse the "detail" member for information; extensions are more suitable and less error-prone ways to obtain such information.

"instance" The "instance" member is a JSON string containing a URI reference that identifies the specific occurrence of the problem. When the "instance" URI is dereferenceable, the problem details object can be fetched from it. It might also return information about the problem occurrence in other formats through use of proactive content negotiation (see ). When the "instance" URI is not dereferenceable, it serves as a unique identifier for the problem occurrence that may be of significance to the server, but is opaque to the client. When "instance" contains a relative URI, it is resolved relative to the document's base URI, as per . However, using relative URIs can cause confusion, and they might not be handled correctly by all implementations. For example, if the two resources "https://api.example.org/foo/bar/123" and "https://api.example.org/widget/456" both respond with an "instance" equal to the relative URI reference "example-instance", when resolved they will identify different resources ("https://api.example.org/foo/bar/example-instance" and "https://api.example.org/widget/example-instance" respectively). As a result, it is RECOMMENDED that absolute URIs be used in "instance" when possible, and that when relative URIs are used, they include the full path (e.g., "/instances/123").

Extension Members Problem type definitions MAY extend the problem details object with additional members that are specific to that problem type. For example, our "out of credit" problem above defines two such extensions -- "balance" and "accounts" to convey additional, problem-specific information. Similarly, the "validation error" example defines a "errors" extension that contains a list of individual error occurrences found, with details and a pointer to the location of each. Clients consuming problem details MUST ignore any such extensions that they don't recognize; this allows problem types to evolve and include additional information in the future. Future updates to this specification might define additional members that are available to all problem types, distinguished by a name starting with "*". To avoid conflicts, extension member names SHOULD NOT start with the "*" character. When creating extensions, problem type authors should choose their names carefully. To be used in the XML format (see ), they will need to conform to the Name rule in . To be used in the HTTP field (see ), they will need to conform to the Dictionary key syntax defined in . Problem type authors that wish their extensions to be usable in the Problem HTTP field (see ) will also need to define the Structured Type(s) that their values are mapped to.

The Problem HTTP Field Some problems might best be conveyed in a HTTP header or trailer field, rather than in the message content. For example, when a problem does not prevent a successful response from being generated, or when the problem's details are useful to software that does not inspect the response content. The Problem HTTP field allows a limited expression of a problem object in HTTP headers or trailers. It is a Dictionary Structured Field () that can contain the following keys, whose semantics and related requirements are inherited from problem objects:

type:

the type value (see ), as a String

status:

the status value (see ), as an Integer

title:

The title value (see ), as a String

detail:

The detail value (see ), as a String

instance:

The instance value (see ), as a String

The title and detail values MUST NOT be serialized in the Problem field if they contain characters that are not allowed by String; see . Practically, this has the effect of limiting them to ASCII strings. An extension member (see ) MAY occur in the Problem field if its name is compatible with the syntax of Dictionary keys (see ) and if the defining problem type specifies a Structured Type to serialize the value into. For example:

Defining New Problem Types When an HTTP API needs to define a response that indicates an error condition, it might be appropriate to do so by defining a new problem type. Before doing so, it's important to understand what they are good for, and what's better left to other mechanisms. Problem details are not a debugging tool for the underlying implementation; rather, they are a way to expose greater detail about the HTTP interface itself. Designers of new problem types need to carefully consider the Security Considerations (), in particular, the risk of exposing attack vectors by exposing implementation internals through error messages. Likewise, truly generic problems -- i.e., conditions that might apply to any resource on the Web -- are usually better expressed as plain status codes. For example, a "write access disallowed" problem is probably unnecessary, since a 403 Forbidden status code in response to a PUT request is self-explanatory. Finally, an application might have a more appropriate way to carry an error in a format that it already defines. Problem details are intended to avoid the necessity of establishing new "fault" or "error" document formats, not to replace existing domain-specific formats. That said, it is possible to add support for problem details to existing HTTP APIs using HTTP content negotiation (e.g., using the Accept request header to indicate a preference for this format; see ). New problem type definitions MUST document:

1. a type URI (typically, with the "http" or "https" scheme),
2. a title that appropriately describes it (think short), and
3. the HTTP status code for it to be used with.

Problem type definitions MAY specify the use of the Retry-After response header () in appropriate circumstances. A problem's type URI SHOULD resolve to HTML documentation that explains how to resolve the problem. A problem type definition MAY specify additional members on the problem details object. For example, an extension might use typed links to another resource that machines can use to resolve the problem. If such additional members are defined, their names SHOULD start with a letter (ALPHA, as per ) and SHOULD comprise characters from ALPHA, DIGIT (), and "_" (so that it can be serialized in formats other than JSON), and they SHOULD be three characters or longer.

Example For example, if you are publishing an HTTP API to your online shopping cart, you might need to indicate that the user is out of credit (our example from above), and therefore cannot make the purchase. If you already have an application-specific format that can accommodate this information, it's probably best to do that. However, if you don't, you might use one of the problem details formats -- JSON if your API is JSON-based, or XML if it uses that format. To do so, you might look in the registry () for an already-defined type URI that suits your purposes. If one is available, you can reuse that URI. If one isn't available, you could mint and document a new type URI (which ought to be under your control and stable over time), an appropriate title and the HTTP status code that it will be used with, along with what it means and how it should be handled.

Registered Problem Types This specification defines the HTTP Problem Type registry for common, widely-used problem type URIs, to promote reuse. The policy for this registry is Specification Required, per . When evaluating requests, the Expert(s) should consider community feedback, how well-defined the problem type is, and this specification's requirements. Vendor-specific, application-specific, and deployment-specific values are not registrable. Specification documents should be published in a stable, freely available manner (ideally located with a URL), but need not be standards. Registrations MAY use the prefix "https://iana.org/assignments/http-problem-types#" for the type URI. Registration requests should use the following template:

• Type URI: [a URI for the problem type]
• Title: [a short description of the problem type]
• Recommended HTTP status code: [what status code is most appropriate to use with the type]
• Reference: [to a specification defining the type]

See the registry at https://iana.org/assignments/http-problem-types for details on where to send registration requests.

about:blank This specification registers one Problem Type, "about:blank".

• Type URI: about:blank
• Title: See HTTP Status Code
• Recommended HTTP status code: N/A
• Reference: [this document]

The "about:blank" URI , when used as a problem type, indicates that the problem has no additional semantics beyond that of the HTTP status code. When "about:blank" is used, the title SHOULD be the same as the recommended HTTP status phrase for that code (e.g., "Not Found" for 404, and so on), although it MAY be localized to suit client preferences (expressed with the Accept-Language request header). Please note that according to how the "type" member is defined (), the "about:blank" URI is the default value for that member. Consequently, any problem details object not carrying an explicit "type" member implicitly uses this URI.

Security Considerations When defining a new problem type, the information included must be carefully vetted. Likewise, when actually generating a problem -- however it is serialized -- the details given must also be scrutinized. Risks include leaking information that can be exploited to compromise the system, access to the system, or the privacy of users of the system. Generators providing links to occurrence information are encouraged to avoid making implementation details such as a stack dump available through the HTTP interface, since this can expose sensitive details of the server implementation, its data, and so on. The "status" member duplicates the information available in the HTTP status code itself, bringing the possibility of disagreement between the two. Their relative precedence is not clear, since a disagreement might indicate that (for example) an intermediary has changed the HTTP status code in transit (e.g., by a proxy or cache). Generic HTTP software (such as proxies, load balancers, firewalls, and virus scanners) are unlikely to know of or respect the status code conveyed in this member.

IANA Considerations Please update the "application/problem+json" and "application/problem+xml" registrations in the "Media Types" registry to refer to this document. Please create the "HTTP Problem Types Registry" as specified in , and populate it with "about:blank" as per . Please register the following entry into the "Hypertext Transfer Protocol (HTTP) Field Name Registry":

Field Name:

Problem

Status:

Permanent

Reference:

RFC nnnn

References Normative References 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. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Adobe Fastly greenbytes GmbH 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 RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. 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. Informative References This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. This document describes the "about" URI scheme, which is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources. This memo provides information for the Internet community. JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document. JSON Schema defines the media type "application/schema+json", a JSON- based format for describing the structure of JSON data. JSON Schema asserts what a JSON document must look like, ways to extract information from it, and how to interact with it. The "application/ schema-instance+json" media type provides additional feature-rich integration with "application/schema+json" beyond what can be offered for "application/json" documents. International Organization for Standardization WHATWG n.d.

JSON Schema for HTTP Problems This section presents a non-normative JSON Schema for HTTP Problem Details. If there is any disagreement between it and the text of the specification, the latter prevails.

HTTP Problems and XML HTTP-based APIs that use XML can express problem details using the format defined in this appendix. The RELAX NG schema for the XML format is: Note that this schema is only intended as documentation, and not as a normative schema that captures all constraints of the XML format. It is possible to use other XML schema languages to define a similar set of constraints (depending on the features of the chosen schema language). The media type for this format is "application/problem+xml". Extension arrays and objects are serialized into the XML format by considering an element containing a child or children to represent an object, except for elements that contain only child element(s) named 'i', which are considered arrays. For example, the example above appears in XML as follows: https://example.com/probs/out-of-credit Your current balance is 30, but that costs 50. https://example.net/account/12345/msgs/abc 30 https://example.net/account/12345 https://example.net/account/67890 ]]> This format uses an XML namespace, primarily to allow embedding it into other XML-based formats; it does not imply that it can or should be extended with elements or attributes in other namespaces. The RELAX NG schema explicitly only allows elements from the one namespace used in the XML format. Any extension arrays and objects MUST be serialized into XML markup using only that namespace. When using the XML format, it is possible to embed an XML processing instruction in the XML that instructs clients to transform the XML, using the referenced XSLT code . If this code is transforming the XML into (X)HTML, then it is possible to serve the XML format, and yet have clients capable of performing the transformation display human-friendly (X)HTML that is rendered and displayed at the client. Note that when using this method, it is advisable to use XSLT 1.0 in order to maximize the number of clients capable of executing the XSLT code.

Using Problem Details with Other Formats In some situations, it can be advantageous to embed problem details in formats other than those described here. For example, an API that uses HTML might want to also use HTML for expressing its problem details. Problem details can be embedded in other formats either by encapsulating one of the existing serializations (JSON or XML) into that format or by translating the model of a problem detail (as specified in ) into the format's conventions. For example, in HTML, a problem could be embedded by encapsulating JSON in a script tag: { "type": "https://example.com/probs/out-of-credit", "title": "You do not have enough credit.", "detail": "Your current balance is 30, but that costs 50.", "instance": "/account/12345/msgs/abc", "balance": 30, "accounts": ["/account/12345", "/account/67890"] } ]]> or by inventing a mapping into RDFa . This specification does not make specific recommendations regarding embedding problem details in other formats; the appropriate way to embed them depends both upon the format in use and application of that format.

Acknowledgements The authors would like to thank Jan Algermissen, Subbu Allamaraju, Mike Amundsen, Roy Fielding, Eran Hammer, Sam Johnston, Mike McCall, Julian Reschke, and James Snell for review of this specification.