Internet DRAFT - draft-divilly-user-defined-resource-error

draft-divilly-user-defined-resource-error







Network Working Group                                         C. Divilly
Internet-Draft                                                    Oracle
Intended status: Informational                             26 March 2020
Expires: 27 September 2020


              User Defined Resource Error HTTP Status Code
              draft-divilly-user-defined-resource-error-00

Abstract

   This document specifies an additional HyperText Transfer Protocol
   (HTTP) status code to indicate server error conditions arising during
   evaluation of a user defined resource hosted by the server, rather
   than in the server itself.

Conventions and Terminology

   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].

Status of This Memo

   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 27 September 2020.

Copyright Notice

   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



Divilly                 Expires 27 September 2020               [Page 1]

Internet-Draft   User Defined Resource Error Status Code      March 2020


   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.

Table of Contents

   1.  Note to Readers . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Why does 500 Internal Server Error not suffice? . . . . .   2
   3.  5NN User Defined Resource Error . . . . . . . . . . . . . . .   4
     3.1.  Relationship to 500 Internal Server Error . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Note to Readers

   Per [RFC7231] Section 8.2.2 (https://tools.ietf.org/html/
   rfc7231#section-8.2.2) this document avoids allocating a specific
   number for the proposed new HTTP status code until there is clear
   consensus that it will be registered.  The code "5NN" is used
   throughout this document to denote this new status code.

2.  Introduction

   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 is 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 5NN 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.

2.1.  Why does 500 Internal Server Error not suffice?

   This section is non normative.

   The current state of the art is to represent errors in User Defined
   Resources as a 500 Internal Server Error status.  In the author's
   experience this is not optimal for the following reasons:



Divilly                 Expires 27 September 2020               [Page 2]

Internet-Draft   User Defined Resource Error Status Code      March 2020


   *  It is widely understood that a 500 Internal Server Error
      represents a serious error condition that likely needs remediation
      by the server's operators

   *  Error conditions in User Defined Resources are frequent and
      expected.  In a well architected system with isolation between the
      environment executing the User Defined Resource program and the
      server hosting the User Defined Resource, errors should be benign
      and not require any remediation by the server's operators

   In the author's own experience we have attempted to address this by
   taking two actions:

   1.  Add an additional response header to enable tools to detect that
       the error condition relates to a user defined resource and should
       not be treated as an error that requires remediation

   2.  Add explanatory text to the response body to communicate to the
       end user that the error represents a problem in a User Defined
       Resource

   Our experience is that these approaches have very limited
   effectiveness:

   *  The additional response header is lost in access logs which are
      often the resource that is used for monitoring the status of the
      server.

   *  Users do not read or understand the explanatory text well enough.
      They see the well known 500 Internal Server Error status code and
      feel they understand that this means there is a problem with the
      server.  Too often they proceed to filing support tickets against
      the server operator, rather than against the developer responsible
      for the hosted User Defined Resource.  This wastes the user's,
      server operators', and User Defined Resource developer's time and
      resources.

   We believe there is substantial value in assigning a new 5NN class
   HTTP status code for this class of server error.  It will be a very
   clear signal to both tools and users that the error condition needs
   to be handled in a distinctly different manner to how 500 Internal
   Server Error conditions are handled.

   Traditionally there has been some kind of direct relationship between
   the author of server resources and the operator of the server.  With
   the rise of multi-tenant hosted platforms (such as 'serverless'
   plaforms) increasingly there is no direct relationship between the
   party hosting the User Defined Resource and the party that authored



Divilly                 Expires 27 September 2020               [Page 3]

Internet-Draft   User Defined Resource Error Status Code      March 2020


   the User Defined Resource, and thus it becomes appropriate to
   distinguish at the HTTP status code level between these two classes
   of error.

3.  5NN User Defined Resource Error

   The 5NN (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.

   A 5NN response is not cacheable.

   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.

3.1.  Relationship to 500 Internal Server Error

   The "5NN" status code can be considered a specialization of the "500"
   status code.  To quote the HTTP Specification
   (https://tools.ietf.org/html/rfc7231#section-6) [RFC7231]:

   |  HTTP status codes are extensible.  HTTP clients are not required
   |  to understand the meaning of all registered status codes, though



Divilly                 Expires 27 September 2020               [Page 4]

Internet-Draft   User Defined Resource Error Status Code      March 2020


   |  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 "5NN" status code in the same manner as
   they treat the "500" status code.

   The primary value of the "5NN" status code is to enable efficient
   routing of problem reports to the party best placed to remediate the
   error condition.

   In the case of a "5NN" status code the party best placed to remediate
   the error condition is the author of the User Defined Resource.

   In the case of a "500" status code the party best placed to remediate
   the error condition is the server operator.

   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 5NN 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 5NN status codes provides
   a strong signal enabling both tools and humans to respond to the
   appropriate party to remediate the error condition.

4.  IANA Considerations

   The HTTP Status Codes Registry (https://www.iana.org/assignments/
   http-status-codes/http-status-codes.xhtml) should be updated with the
   following entry:

   *  Code: 5NN

   *  Description: User Defined Resource Error

   *  Specification: [ this document ]







Divilly                 Expires 27 September 2020               [Page 5]

Internet-Draft   User Defined Resource Error Status Code      March 2020


5.  Security Considerations

   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 (https://tools.ietf.org/html/
   rfc7230#section-9.8) for relevant guidance on this topic.

6.  Example

   This section is non-normative.

   Below is an example response that leverages the Problem Details for
   HTTP APIs (https://tools.ietf.org/html/rfc7807) syntax [RFC7807] to
   communicate information about the error condition:

   HTTP/1.1 5NN 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"
   }

   *  The "detail" message is careful to reveal minimal information
      about the User Defined Resource that experienced the error
      condition.

   *  The "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.

   *  The "instance" URI points to a (secured) resource that can be
      interrogated to view all the log messages associated with this
      specific error instance.

7.  Normative References





Divilly                 Expires 27 September 2020               [Page 6]

Internet-Draft   User Defined Resource Error Status Code      March 2020


   [RFC7807]  Nottingham, M. and E. Wilde, "Problem Details for HTTP
              APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
              <https://www.rfc-editor.org/info/rfc7807>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <https://www.rfc-editor.org/info/rfc7230>.

Author's Address

   Colm Divilly
   Oracle

   Email: colm.divilly@oracle.com





















Divilly                 Expires 27 September 2020               [Page 7]