Internet-Draft | 555 HTTP Status Code | March 2020 |
Divilly | Expires 21 September 2020 | [Page] |
This document specifies an additional HyperText Transfer Protocol (HTTP) status code to indicate server error conditions arising during evaluation of user defined resources hosted by the server.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 September 2020.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Some HTTP servers offer mechanisms for users to define their own programmatically generated resources. This specification terms such a resource as a 'User Defined Resource'. In such cases it may be useful to distinguish between errors arising due to defects in the User Defined Resource and errors arising due to defects in the server itself.¶
This document proposes a new HTTP status code. This status code indicates that an error occurred when the server attempted to produce a representation of the User Defined Resource, and the error occurred when attempting to evaluate the program that generates the resource, rather than an error condition in the server itself.¶
The 555 (User Defined Resource Error) status code indicates that the server encountered an unexpected condition when evaluating a User Defined Resource that prevented the server from fulfilling the request.¶
The response message MAY contain information that identifies the User Defined Resource that originated the error. The response message SHOULD contain additional information that can help the author of User Defined Resource diagnose the root cause of the error.¶
The response SHOULD include an identifier that uniquely identifies the error condition instance. This identifier should also appear with any log messages or other diagnostic information that the server produces.¶
The response MAY include a URI [RFC3986] that points to a resource that the User Defined Resource author can use to review the log and other diagnostic information associated with the error condition. Access to this URI MUST be restricted to ensure only the User Defined Resource author can access it.¶
It is RECOMMENDED that the server provide the User Defined Resource author with secured access to the logs pertaining to the error instance, and a capability to filter/search these logs keyed by the error identifier.¶
The log information SHOULD provide detailed information about the nature and origin of the error, to enable the User Defined Resource author to diagnose the root cause of the error, whereas the error response SHOULD contain the minimal information required to identify the corresponding log messages.¶
The 555
status code can be considered a specialization of the 500
status
code. To quote the
HTTP Specification [RFC7231]:¶
HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class¶
Thus clients SHOULD treat the 555
status code in the same manner as they
treat the 500
status code.¶
The primary value of the 555
status code is to enable operators of a server
to easily distinguish between error conditions arising due to problems in the
server itself, and error conditions arising due to problems in a User Defined
Resource.¶
A 500 status is unexpected and likely requires a corrective action from the server operators, as the error may indicate a threat to the stability and availability of the server.¶
A 555 status is likely to be commonplace, as User Defined Resource authors will be expected to make mistakes when authoring those resources. Assuming a well architected server with proper isolation between the server and the User Defined Resources, such error conditions are unlikely to be a threat to the stability and availability of the server.¶
The ability to distinguish between 500 and 555 status codes provides similar value to User Defined Resource authors and end users of the User Defined Resource.¶
The HTTP Status Codes Registry should be updated with the following entry:¶
When the server includes information that identifies the User Defined Resource that caused the error, or additional information that helps the author diagnose the root cause, care must be taken not to disclose information that may be useful to an attacker.¶
Care needs to be taken to ensure that the log messages do not reveal sensitive information about the users of the User Defined Resource, see [RFC7230] section 9.8 for relevant guidance on this topic.¶
This section is non-normative.¶
Below is an example response that leverages the Problem Details for HTTP APIs syntax [RFC7807] to communicate information about the error condition:¶
HTTP/1.1 555 User Defined Resource Error Content-Type: application/problem+json Content-Language: en { "type": "https://example.com/errs/user-defined-resource-error", "title": "User Defined Resource Error", "detail": "An unexpected error condition occurred when evaluating a user defined resource", "trace_id": "a75382c4-d61d-4c16-8dde-a01afc7b51a2", "instance": "/logs/?trace_id=a75382c4-d61d-4c16-8dde-a01afc7b51a2" }¶
detail
message is careful to reveal minimal information about the User
Defined Resource that experienced the error condition.¶
trace_id
field provides a unique identifier for the error condition that
can be used to correlate corresponding log entries and other diagnostic
information relevant to this error condition.¶
instance
URI points to a (secured) resource that can be interrogated to
view all the log messages associated with this specific error instance.¶