draft-inadarei-api-health-check-02.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc ipr="trust200902" docName="draft-inadarei-api-health-check-02" category="info">

  <front>
    <title>Health Check Response Format for HTTP APIs</title>

    <author initials="I." surname="Nadareishvili" fullname="Irakli Nadareishvili">
      <organization></organization>
      <address>
        <postal>
          <street>114 5th Avenue</street>
          <city>New York</city>
          <country>United States</country>
        </postal>
        <email>irakli@gmail.com</email>
        <uri>http://www.freshblurbs.com</uri>
      </address>
    </author>

    <date year="2018"/>

    <area>General</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document proposes a service health check response format for HTTP APIs.</t>



    </abstract>


    <note title="Note to Readers">


<t><spanx style="strong">RFC EDITOR: please remove this section before publication</spanx></t>

<t>The issues list for this draft can be found at <eref target="https://github.com/inadarei/rfc-healthcheck/issues">https://github.com/inadarei/rfc-healthcheck/issues</eref>.</t>

<t>The most recent draft is at <eref target="https://inadarei.github.io/rfc-healthcheck/">https://inadarei.github.io/rfc-healthcheck/</eref>.</t>

<t>Recent changes are listed at <eref target="https://github.com/inadarei/rfc-healthcheck/commits/master">https://github.com/inadarei/rfc-healthcheck/commits/master</eref>.</t>

<t>See also the draft’s current status in the IETF datatracker, at
<eref target="https://datatracker.ietf.org/doc/draft-inadarei-api-health-check/">https://datatracker.ietf.org/doc/draft-inadarei-api-health-check/</eref>.</t>


    </note>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The vast majority of modern APIs driving data to web and mobile applications use
HTTP <xref target="RFC7230"/> as their protocol. The health and uptime of these APIs
determine availability of the applications themselves. In distributed systems
built with a number of APIs, understanding the health status of the APIs and
making corresponding decisions, for caching, failover or circuit-breaking, are
essential to the ability of providing highly-available solutions.</t>

<t>There exists a wide variety of operational software that relies on the ability
to read health check response of APIs. However, there is currently no standard
for the health check output response, so most applications either rely on the
basic level of information included in HTTP status codes <xref target="RFC7231"/> or use
task-specific formats.</t>

<t>Usage of task-specific or application-specific formats creates significant
challenges, disallowing any meaningful interoperability across different
implementations and between different tooling.</t>

<t>Standardizing a format for health checks can provide any of a number of
benefits, including:</t>

<t><list style="symbols">
  <t>Flexible deployment - since operational tooling and API clients can rely on
rich, uniform format, they can be safely combined and substituted as needed.</t>
  <t>Evolvability - new APIs, conforming to the standard, can safely be introduced
in any environment and ecosystem that also conforms to the same standard,
without costly coordination and testing requirements.</t>
</list></t>

<t>This document defines a “health check” format using the JSON format <xref target="RFC8259"/>
for APIs to use as a standard point for the health information they offer.
Having a well-defined format for this purpose promotes good practice and
tooling.</t>

</section>
<section anchor="notational-conventions" title="Notational Conventions">

<t>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 <xref target="RFC2119"/>.</t>

</section>
<section anchor="api-health-response" title="API Health Response">

<t>Health Check Response Format for HTTP APIs uses the JSON format described in
<xref target="RFC8259"/> and has the media type “application/health+json”.</t>

<t>Its content consists of a single mandatory root field (“status”) and several
optional fields:</t>

<section anchor="status" title="status">

<t>status: (required) indicates whether the service status is acceptable or not.
API publishers SHOULD use following values for the field:</t>

<t><list style="symbols">
  <t>“pass”: healthy (acceptable aliases: “ok” to support Node’s Terminius and
“up” for Java’s SpringBoot),</t>
  <t>“fail”: unhealthy (acceptable aliases: “error” to support Node’s Terminius and
“down” for Java’s SpringBoot), and</t>
  <t>“warn”: healthy, with some concerns.</t>
</list></t>

<t>The value of the status field is case-insensitive and is tightly related with
  the HTTP response code returned by the health endpoint. For “pass” and “warn”
  statuses, HTTP response code in the 2xx-3xx range MUST be used. For “fail”
  status, HTTP response code in the 4xx-5xx range MUST be used. In case of the
  “warn” status, endpoints SHOULD return HTTP status in the 2xx-3xx range, and
  additional information SHOULD be provided, utilizing optional fields of the
  response.</t>

<t>A health endpoint is only meaningful in the context of the component it
  indicates the health of. It has no other meaning or purpose. As such, its
  health is a conduit to the health of the component. Clients SHOULD assume that
  the HTTP response code returned by the health endpoint is applicable to the
  entire component (e.g. a larger API or a microservice). This is compatible
  with the behavior that current infrastructural tooling expects:
  load-balancers, service discoveries and others, utilizing health-checks.</t>

</section>
<section anchor="version" title="version">

<t>version: (optional) public version of the service.</t>

</section>
<section anchor="releaseid" title="releaseId">

<t>releaseId: (optional) in well-designed APIs, backwards-compatible changes in
  the service should not update a version number. APIs usually change their
  version number as infrequently as possible, to preserve stable interface.
  However implementation of an API may change much more frequently, which leads
  to the importance of having separate “release number” or “releaseID” that is
  different from the public version of the API.</t>

</section>
<section anchor="notes" title="notes">

<t>notes: (optional) array of notes relevant to current state of health</t>

</section>
<section anchor="output" title="output">

<t>output: (optional) raw error output, in case of “fail” or “warn” states. This
  field SHOULD be omitted for “pass” state.</t>

</section>
<section anchor="details" title="details">

<t>details (optional) is an object that provides more details about the status of
the service as it pertains to the information about the downstream dependencies
of the service in question. Please refer to the “The Details Object” section
for more information.</t>

</section>
<section anchor="links" title="links">

<t>links (optional) is an array of objects containing link relations and URIs
<xref target="RFC3986"/> for external links that MAY contain more information about the
health of the endpoint. Per web-linking standards <xref target="RFC8288"/> a link
relationship SHOULD either be a common/registered one or be indicated as a URI,
to avoid name clashes.  If a “self” link is provided, it MAY be used by clients
to check health via HTTP response code, as mentioned above.</t>

</section>
<section anchor="serviceid" title="serviceId">

<t>serviceId (optional) is a unique identifier of the service, in the application
scope.</t>

</section>
<section anchor="description" title="description">

<t>description (optional) is a human-friendly description of the service.</t>

</section>
</section>
<section anchor="the-details-object" title="The Details Object">

<t>The “details” object MAY have a number of unique keyes, one for each logical
downstream dependencies or sub-components. Since each sub-component may be
backed by several nodes with varying health statuses, these keys point to arrays
of objects. In case of a single-node sub-component (or if presence of nodes is
not relevant), a single-element array should be used as the value, for
consistency.</t>

<t>The key identifying an element in the object should be a unique string within
the details section. It MAY have two parts: “{componentName}:{measurementName}”,
in which case the meaning of the parts SHOULD be as follows:</t>

<t><list style="symbols">
  <t>componentName: (optional) human-readable name for the component. MUST not 
contain a colon, in the name, since colon is used as a separator.</t>
  <t>measurementName: (optional) name of the measurement type (a data point type)
that the status is reported for. MUST not contain a colon, in the name, since
colon is used as a separator. The observation’s name can be one of:
  <list style="symbols">
      <t>A pre-defined value from this spec. Pre-defined values include:
      <list style="symbols">
          <t>utilization</t>
          <t>responseTime</t>
          <t>connections</t>
          <t>uptime</t>
        </list></t>
      <t>A common and standard term from a well-known source such as schema.org, IANA
or microformats.</t>
      <t>A URI that indicates extra semantics and processing rules that MAY be
provided by a resource at the other end of the URI. URIs do not have to be
dereferenceable, however. They are just a namespace, and the meaning of a
namespace CAN be provided by any convenient means (e.g. publishing an RFC,
Swagger document or a nicely printed book).</t>
    </list></t>
</list></t>

<t>On the value side of the equation, each “component details” object in the array
MAY have one of the following object keys:</t>

<section anchor="componentid" title="componentId">

<t>componentId: (optional) is a unique identifier of an instance of a specific
sub-component/dependency of a service. Multiple objects with the same
componentID MAY appear in the details, if they are from different nodes.</t>

</section>
<section anchor="componenttype" title="componentType">

<t>componentType: (optional) SHOULD be present if componentName is present. It’s
a type of the component and could be one of:</t>

<t><list style="symbols">
  <t>Pre-defined value from this spec. Pre-defined values include:
  <list style="symbols">
      <t>component</t>
      <t>datastore</t>
      <t>system</t>
    </list></t>
  <t>A common and standard term from a well-known source such as schema.org, IANA
or microformats.</t>
  <t>A URI that indicates extra semantics and processing rules that MAY be
provided by a resource at the other end of the URI. URIs do not have to be
dereferenceable, however. They are just a namespace, and the meaning of a
namespace CAN be provided by any convenient means (e.g. publishing an RFC,
Swagger document or a nicely printed book).</t>
</list></t>

</section>
<section anchor="observedvalue" title="observedValue">

<t>observedValue: (optional) could be any valid JSON value, such as: string, number,
object, array or literal.</t>

</section>
<section anchor="observedunit" title="observedUnit">

<t>observedUnit (optional) SHOULD be present if observedValue is present. Calrifies
the unit of measurement in which observedUnit is reported, e.g. for a time-based
value it is important to know whether the time is reported in seconds, minutes,
hours or something else. To make sure unit is denoted by a well-understood name
or an abbreviation, it should be one of:</t>

<t><list style="symbols">
  <t>A common and standard term from a well-known source such as schema.org, IANA,
microformats, or a standards document such as <xref target="RFC3339"/>.</t>
  <t>A URI that indicates extra semantics and processing rules that MAY be
provided by a resource at the other end of the URI. URIs do not have to be
dereferenceable, however. They are just a namespace, and the meaning of a
namespace CAN be provided by any convenient means (e.g. publishing an RFC,
Swagger document or a nicely printed book).</t>
</list></t>

</section>
<section anchor="status-1" title="status">

<t>status (optional) has the exact same meaning as the top-level “output”
element, but for the sub-component/downstream dependency represented
by the details object.</t>

</section>
<section anchor="time" title="time">

<t>time (optional) is the date-time, in ISO8601 format, at which the reading of the
observedValue was recorded. This assumes that the value can be cached and the
reading typically doesn’t happen in real time, for performance and scalability
purposes.</t>

</section>
<section anchor="output-1" title="output">

<t>output (optional) has the exact same meaning as the top-level “output”
element, but for the sub-component/downstream dependency represented
by the details object.</t>

</section>
<section anchor="links-1" title="links">

<t>links (optional) has the exact same meaning as the top-level “output”
element, but for the sub-component/downstream dependency represented
by the details object.</t>

</section>
</section>
<section anchor="example-output" title="Example Output">

<figure><artwork><![CDATA[
  GET /health HTTP/1.1
  Host: example.org
  Accept: application/health+json

  HTTP/1.1 200 OK
  Content-Type: application/health+json
  Cache-Control: max-age=3600
  Connection: close

{
  "status": "pass",
  "version": "1",
  "releaseID": "1.2.2",
  "notes": [""],
  "output": "",
  "serviceID": "f03e522f-1f44-4062-9b55-9587f91c9c41",
  "description": "health of authz service",
  "details": {
    "cassandra:responseTime": [
      {
        "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d2",
        "componentType": "datastore",
        "observedValue": 250,
        "observedUnit": "ms",
        "status": "pass",
        "time": "2018-01-17T03:36:48Z",
        "output": ""
      }
    ],
    "cassandra:connections": [
      {
        "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d2",
        "type": "datastore",
        "observedValue": 75,
        "status": "warn",
        "time": "2018-01-17T03:36:48Z",
        "output": "",
        "links": {
          "self": "http://api.example.com/dbnode/dfd6cf2b/health"
        }
      }
    ],
    "uptime": [
      {
        "componentType": "system",
        "observedValue": 1209600.245,
        "observedUnit": "s",
        "status": "pass",
        "time": "2018-01-17T03:36:48Z"
      }
    ],
    "cpu:utilization": [
      {
        "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227",
        "node": 1,
        "componentType": "system",
        "observedValue": 85,
        "observedUnit": "percent",
        "status": "warn",
        "time": "2018-01-17T03:36:48Z",
        "output": ""
      },
      {
        "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227",
        "node": 2,
        "componentType": "system",
        "observedValue": 85,
        "observedUnit": "percent",
        "status": "warn",
        "time": "2018-01-17T03:36:48Z",
        "output": ""
      }
    ],
    "memory:utilization": [
      {
        "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227",
        "node": 1,
        "componentType": "system",
        "observedValue": 8.5,
        "observedUnit": "GiB",
        "status": "warn",
        "time": "2018-01-17T03:36:48Z",
        "output": ""
      },
      {
        "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227",
        "node": 2,
        "componentType": "system",
        "observedValue": 5500,
        "observedUnit": "MiB",
        "status": "pass",
        "time": "2018-01-17T03:36:48Z",
        "output": ""
      }
    ]
  },
  "links": {
    "about": "http://api.example.com/about/authz",
    "http://api.x.io/rel/thresholds":
      "http://api.x.io/about/authz/thresholds"
  }
}
]]></artwork></figure>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>Clients need to exercise care when reporting health information. Malicious
actors could use this information for orchestrating attacks. In some cases the
health check endpoints may need to be authenticated and institute role-based
access control.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>The media type for health check response is application/health+json.</t>

<t><list style="symbols">
  <t>Media type name: application</t>
  <t>Media subtype name: health+json</t>
  <t>Required parameters: n/a</t>
  <t>Optional parameters: n/a</t>
  <t>Encoding considerations: binary</t>
  <t>Security considerations: Health+JSON shares security issues common to all JSON
  content types. See RFC 8259 Section #12 for additional information.  <vspace blankLines='1'/>
Health+JSON allows utilization of Uniform Resource Identifiers (URIs) and as such
  shares security issues common to URI usage. See RFC 3986 Section #7
  for additional information.  <vspace blankLines='1'/>
Since health+json can carry wide variety of data, some data may require privacy
  or integrity services. This specification does not prescribe any specific
  solution and assumes that concrete implementations will utilize common, trusted
  approaches such as TLS/HTTPS, OAuth2 etc.</t>
  <t>Interoperability considerations: None</t>
  <t>Published specification: this RFC draft</t>
  <t>Applications which use this media: Various</t>
  <t>Fragment identifier considerations: Health+JSON follows RFC6901 for implementing
URI Fragment Identification standard to JSON content types.</t>
  <t>Restrictions on usage: None</t>
  <t>Additional information:
  <list style="numbers">
      <t>Deprecated alias names for this type: n/a</t>
      <t>Magic number(s): n/a</t>
      <t>File extension(s): .json</t>
      <t>Macintosh file type code: TEXT</t>
      <t>Object Identifiers: n/a</t>
    </list></t>
  <t>General Comments:</t>
  <t>Person to contact for further information:
  <list style="numbers">
      <t>Name: Irakli Nadareishvili</t>
      <t>Email: irakli@gmail.com</t>
    </list></t>
  <t>Intended usage: Common</t>
  <t>Author/Change controller: Irakli Nadareishvili</t>
</list></t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>Thanks to  Mike Amundsen, Erik Wilde, Justin Bachorik and Randall Randall for
their suggestions and feedback. And to Mark Nottingham for blueprint for
authoring RFCs easily.</t>

</section>
<section anchor="creating-and-serving-health-responses" title="Creating and Serving Health Responses">

<t>When making an health check endpoint available, there are a few things to keep
in mind:</t>

<t><list style="symbols">
  <t>A health response endpoint is best located at a memorable and commonly-used
URI, such as “health” because it will help self-discoverability by clients.</t>
  <t>Health check responses can be personalized. For example, you could advertise
different URIs, and/or different kinds of link relations, to afford different
clients access to additional health check information.</t>
  <t>Health check responses SHOULD be assigned a freshness lifetime (e.g.,
“Cache-Control: max-age=3600”) so that clients can determine how long they
could cache them, to avoid overly frequent fetching and unintended DDOS-ing of
the service. Any method of cach lifetime negotiation provided by HTTP spec is
acceptable (e.g. ETags are just fine).</t>
  <t>Custom link relation types, as well as the URIs for variables, should lead to
documentation for those constructs.</t>
</list></t>

</section>
<section anchor="consuming-health-check-responses" title="Consuming Health Check Responses">

<t>Clients might use health check responses in a variety of ways.</t>

<t>Note that the health check response is a “living” document; links from the
health check response MUST NOT be assumed to be valid beyond the freshness
lifetime of the health check response, as per HTTP’s caching model <xref target="RFC7234"/>.</t>

<t>As a result, clients ought to cache the health check response (as per
<xref target="RFC7234"/>), to avoid fetching it before every interaction (which would
otherwise be required).</t>

<t>Likewise, a client encountering a 404 (Not Found) on a link is encouraged to obtain
a fresh copy of the health check response, to assure that it is up-to-date.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC3986" target='https://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<date year='2005' month='January' />
<abstract><t>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]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>



<reference  anchor="RFC8288" target='https://www.rfc-editor.org/info/rfc8288'>
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<date year='2017' month='October' />
<abstract><t>This specification defines a model for the relationships between resources on the Web (&quot;links&quot;) and the type of those relationships (&quot;link relation types&quot;).</t><t>It also defines the serialisation of such links in HTTP headers with the Link header field.</t></abstract>
</front>
<seriesInfo name='RFC' value='8288'/>
<seriesInfo name='DOI' value='10.17487/RFC8288'/>
</reference>



<reference  anchor="RFC7234" target='https://www.rfc-editor.org/info/rfc7234'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='RFC' value='7234'/>
<seriesInfo name='DOI' value='10.17487/RFC7234'/>
</reference>



<reference  anchor="RFC8259" target='https://www.rfc-editor.org/info/rfc8259'>
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials='T.' surname='Bray' fullname='T. Bray' role='editor'><organization /></author>
<date year='2017' month='December' />
<abstract><t>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.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name='STD' value='90'/>
<seriesInfo name='RFC' value='8259'/>
<seriesInfo name='DOI' value='10.17487/RFC8259'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC7230" target='https://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>



<reference  anchor="RFC6838" target='https://www.rfc-editor.org/info/rfc6838'>
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials='N.' surname='Freed' fullname='N. Freed'><organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></author>
<author initials='T.' surname='Hansen' fullname='T. Hansen'><organization /></author>
<date year='2013' month='January' />
<abstract><t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols.  This memo documents an Internet Best Current Practice.</t></abstract>
</front>
<seriesInfo name='BCP' value='13'/>
<seriesInfo name='RFC' value='6838'/>
<seriesInfo name='DOI' value='10.17487/RFC6838'/>
</reference>



<reference  anchor="RFC7231" target='https://www.rfc-editor.org/info/rfc7231'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/>
</reference>



<reference  anchor="RFC3339" target='https://www.rfc-editor.org/info/rfc3339'>
<front>
<title>Date and Time on the Internet: Timestamps</title>
<author initials='G.' surname='Klyne' fullname='G. Klyne'><organization /></author>
<author initials='C.' surname='Newman' fullname='C. Newman'><organization /></author>
<date year='2002' month='July' />
<abstract><t>This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.</t></abstract>
</front>
<seriesInfo name='RFC' value='3339'/>
<seriesInfo name='DOI' value='10.17487/RFC3339'/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIAKIIxFsAA+1c7XLbyJX9j6fo4vyI7ZCUREuyxP2oVWxPrOzYmrXkZLOp
qVQTaIoYgQCDBkQzU57Kg+y+XJ5kz7m3GwQl2Z5kJ1vZbPJjTAGN27fv57m3
uzMajZImbwo3Na+cLZqFeb5w6Y156/yqKr0zX1b10jZmXtXm1dXV1+bs63Of
2NmsdrfTJKvS0i7xbVbbeTPKS5vZ2uUju8pHCyE3SklutD9JMttg4GT/4CRJ
8fO6qjdTk5fzKknyVT01Td36ZrK/f4qxIGKn5ueudLUtknVV31zXVbuaJjdu
g7+yqTkvG1eXrhm94MxJ4htbZr+1RVViko3zySqfmt80VTo0+E9eZq5shsZX
dVO7ucevzTL8aOo8xau0Wq5s+LHEYLzKyyIv3TdJYttmUdXTxIwSg//lpQcD
Y/NGV+sXt3mRyxsVxnltb4r8gdeYy7lmag4ODs0RRH1268rWyas0byCON25t
fo3V6qOqLRsK6V2ZNy4zlw3E5uWVW9q8gPRkon+55l9j8C3v2horXzTNarq3
t16vx/Pa+cWsaOuZlzFJKRrNbx0WZN5++XxycHAafj49PTnmzy/w+2gyOQ6P
TyYnJ+Hns8nTw+7pEb5LqMJdghizH34enzztfXkQp3n6lF+ORiNjZxAK5J4k
V4vcGxhUS+mbVV2tKu+8sca7+jZPnVGDMmJQpo72OX/APsdKu6wa99s3/E9T
/fats5mrfZI8eQIOzMsX51cXb6dmVTgLKrVbVrfONOTBu7TJq9LMHIg6s2pn
RQ6LxaMnT8imM7n3LVgrcq8Ty2fiAia1/BBP2zIz4OsfqQkPVVznzaKdUQN7
0U326nka3EQWtad0/3mssywrkK9dSnEocczSJxnpjAPtvLpHkbTeKol0Yctr
ChRrIufuT+ePrpE3fm9p8XlN2pfOGVv4CiJwyuRPvEnbuuaM8Mmm9XAXeXv+
8upLgyBgqe8bVw8xfdJN33sxzl0zH1f19R6sYe8zkUVWSGUv8ywrXJJ8wdBQ
V1krSlRJ3oJfs7TfVjW8zFRziBa2UIqtgOv8Ni+vhTXECrN2M4NYgjGzvMDq
Vquofm9a7xKxsu++C3b+4YOxnuvLa9osYk1VjA0nDeZKUu2qyZeOE2MgrE1i
aOYgwyUCjLG38F+L2QJ3lNbOtHiw9K64dX6M1ZksZ9CatVSh30AVS5/M2rxo
zDrnjKZslzNXkxRnGhrYIkyfEZILbbbMBQ2FOUUcGJQs7Q0HplWtbiafZS7N
PdkZis2nNl3gMf4A8/AdTIeHeZ22eTNCdhASQ1pb4ryHOeS2oHhlcdu1Qma3
udBf5NeLYjMKwoDkfVW0sn71B5ite4+VMySs84xarWEpQqVaIVFwLObw1bxZ
08ibhaX/FDmMvir7EyfgAxxmHwkpQW5j86pau1taaiPT551pFxsEFyMStXWW
aAy4E6Gqtlm1TUeVyUddeke1LidtsrkJTCYz6/PUFJi5ICtdfMXrvEyLNoPa
4VNih0GBKezZd0Z5AKMERzTWxvqbkV9BdXPQVEKU5ztvr9Ugdwbgqx539z40
KaSGHGR8fl3yhS2bBHGlKBxDy5CWiT+qNfVpy41ZOlvi97wtwDHMXfQUlG/T
uvJwv3w+d5Rpki8RjBn8g2joOTPXrJ0rt6NgQhWy8jVjTxB//nuZrp8J+orw
EpPVzpxwhWX3fCSZAWbMc034FC+oITk9MV8WsDcaYuZWRbWRtDTC0kvkor7B
BY6EX9iNSWFxZaPTBr0i7QFlLOiJOdkMvIphbWLO8HbO0QiyM0SFTOj5Fvkx
b8TVEWdK56D9Mbl7eVsVt1GWyHVADursaSUGI56u7hbtdCgzhWkwYR4CpcsS
ghqRjStv87oqZbFkwKWVhhh1J4n1YQbf0Qfq2U4CWgxDMH8M9I2sCJANEVxM
mERhQg35q93v2rwWnauT9xFABqWUAgAGfXUOop5bH4PZLy4v3sSn4gNEJh8+
iFtKTAOfcAYK0HZ8mlWF9Zs7rtt3NtFNRbsbJ6/srRrZ2hXFSFnL+hYnEGDV
1gQtNLZlRT+5ripMRHxDAMPQujXfLwygSbSh51V5yxgJu9eUBaBriHS9Gbx+
d3k1GOq/5s2F/H778t/enb99+YK/L1+dffVV9yOOuHx18e4rvE/Cr+2Xzy9e
v3755oV+/Prs1/iHShlcfH11fvHm7KuBZuy+LiScVrCZRNx4VbtgkAg7KVKR
RiSRPdHkhw+yPjpDKCpiOZEkP7zKoM78PQX3Z0x62pY1LDQXI+5kOZL5ZuXM
oBfQ9lTLP/3WV+UALJ7TSyusiPAIfEh2kehA24LnL2krDSoVU1cV2MtdkZlH
A426g8fqokwRqFKqVdCljPIIIV98EeOz1Cf4MTWPgs1nj8F/Rr6wxvXCSRYQ
ZwpoN4In2GyaulUjKRHiAagdJ5Ss4FKPz7wJGm4FDsf4e2sLgtRo4MIVmDII
FoOV9X4wDUa/MY96U9giByAGp4MKvgal+3a1QtkEa80cwN2VgJa8VaTAgmPQ
rsQpzS+QuzHiclVj/p9BYI+HOh0hAqZry09P6Oq6qn/gnFm1Lj86axiGmQEE
yu1ChwqQfIV4BX2nwICMO8YoSIS8IhQK0leFM++DRYBQ4Bifs9IRzeN5A9DC
EIc4b+kSpA96JCF23GEKZmj81bQ1A8ds0w86rswkGI3pBuaPf/hPquePf/gv
mQR/chH4MzGBLWbaB6gHnD15/3709P17UxPuGwkaiPX4KuvoUx99gp8idwhy
Rx8hByxKwQShgdyW2Y5yXFxnpSqEHfjyEOdRiTbL8uBY/eAciM1czOzIbkCL
hYKBO764ZTAuUbR+dlcB1GhVFndwi/AmYeJ9E+2D3YKqZNzIG0me0ZV7aq3m
kFAjMQlgsRIPD4TpyCFZjM0Z8FRLcAAMAloxEzFZYdYMeDom2o7wLg9j8zxA
jiAVmA/itmTsP9sYhQENnfRS5QDUmKXqvgAeufH1GLwWtr52knAFRqIgI8DT
aPaYJVEu0Uz6LA1xVQAKMvnMLZBhJVQhxscCEgqvUbrVqOXauoe03HsA08az
m1BUNhvNbGHpzWznhPAJJJqyKiH4pxuJ+H3fRvpVJKMAojXGs8JBuA6/EK+j
KT0OjYBuUIwUOqESQBhgO+E8S5Lu5w4NWFNAEITQLguYbYbCF46T+dFWPF3B
npdBiV1qALhCWEImQGXJthqkHblSWDuOCbQFHN8ESlqlgtbuWKZxChp5SSsb
/A3D9OSBzTM4mOPMEhTJl0CAueWaTSyRzC54lyQq9TVSaDf/ElaOEgjWs50N
IXkBZIxyx2a0/mDpIIf4bwVqz81C0Zd3K1tzuYMg3LCCAQ0uPjt/MVAjyklu
WzfMgcmE9MNqBKuqQjaNPJtkDXNST3W2rq3UDvJKVH1rpSDZaXgow2JbQk/L
wCTRf3co1nZtJOeFQSxAuoCqSVNWJklMiXt1JKxMU9M2DFbLvGkUk4b8rl/o
qjLXgBzWFX7s2CQ9xFSzb+FTKroQUr0qK35iZ8T0veyI2qlvlrQjfOugt7zs
ioN+0N5SYPpmN9QuWV05tmdTuGqy61SUB+zE8+Ox+Tq26uaESkp9wMz9IjB4
IUsYxAae4H9ZQY8HFQeiyA2EIf/cF0WnaZWJYkSsiTbITzTbdzXqu7fnXpEo
26dAopwXuQLoAjFL5xCxAmtHUvf42som2Y3yW3DwNZa9drMRKYo7hErGx6Ln
5IQwWGZMOhYX+SpaSeg1zJxkluUSgLh212wFAo8i8Qm+lLpQs1mmFRPWN2TH
xN5WeSYtbpS4FsgTxmjOiZYH3hXzgcqGZVCXkXNddAAMzDShOCY9bZOE1d4C
r99PUkNysNTCiOzMENJVg8FCGGm7n3c1yWob5mNyNv9zOEx9J2gPY3bv1QgJ
8saq8xrWGittJPb+uDfRokWlMJoj25QZImh/6P00Ye7brNZ8g+Bpg+iMlB1i
n9tp6YVFoUAkDqTWxN4sg2h1jVUUyUe8i+r17WzU5W4o8FLaGfL1ziuJ2zM2
o9Ib1VyocxD+GBkkc9/aerNNpT10qm1OsOhDmU3zoVeJhwe32sGPseQakfwd
Vh6B73yueShkBGUCgZBJMIZiAv9Ixmk2Cr4cMma0w1AlCuKXbmYSqj+Q34y3
BXgwnI12d0ykGYwmKGlLuzM4tmfxCWWE5C3xLqg7hCYBhp12mzWSrK0b1kDf
dct+A0f7MP0OiNG32iORJ6joCSIkaYrwtN4NsFKNTYj1coP1oS700tjamWIn
I6kdszUqmV58PRaQPbgpVQAln5guoDGkFFXZuRS/HYZumbyhp0Tp25jLq3oM
hu6scYcl4SGsqzdOi/tHVtv2wcjw6LFgJbuTp3Jma+IJTY89/n8A87LET7Av
3lzN6N8SP1CKaojUpp5E1TmR6hPUGzDhrnmk9WaAJdx2AqZFkL87wsem71QK
3ycBwWqs0icxZF7lSxceYWGlmpqPn8keROBDo7+2L2I/jLsRyk7oct2UCCMo
ltuamJPYDUv3iNpLy92ZoTk/e3Mm1Jlnifa7/rLOgsQRoFhXHiEt1pQezKzJ
U82fSBep89LNq9vC9ZLlTJcT8wmjkOVqlaWgZC2sHDG+WgmmHUtSBsoQLauT
VZFc5gRCMJRYwbgLxbCiyo30ur5t2acXRfqVTbUYvetpttvylTHm+dmbfj0q
3JbsfrK1l0tMxcc+FEyhfRNCC/L3UMhdru01y6iu9Sa1VInUgbzCFgeNeFZV
N48Rpy7KbRyDtWadowBdi4EMNbIPtrH0boqJCZBhMukiklqt9o26hlL4glFd
m1sdVWbh3h/TH5aILfczfAfyrYnbDclO+N/rUljo3MdUal63RZOvCtfhtK6c
ZEe6x9ELsSYkeWfruOIgiCEzSxP1Lua/rRkky4x313qFINNbLf/cWW+/McF8
1XCCnYirEEneMQ/8xCehVXmvt0CjS2N2iZFEnOtemPgzAkk3T/ibkdQjpMUY
on3/v0eMv52IgdHyidSlkrJc9kvaBsrT/p87Bt0ZIFmDJaEGkH58QE9BzdMA
eoYBqQ4TdcphrKZqlAcNAaT6U5yPZ1u2s/OvzzrTDqs7zvTcFjXDixfM1ZIY
N/t7qKGDTjsz9gACIiZlPRchMmOOZgBZWaJOpmNjc0JgLW1+p4EvW/19yIE5
AfuqMkOwWeZlC6seJgCNtQLyaukaUaor2A28qgC9b+g+dVgCN2Icmw7BnMXV
wpY+95doTwn5ZRHJc1l5iP15H5zuhI8f05/VCvvePFQT3NannWlGGlotP30q
O0V/d/3/FbBwfzdqB/mHmsi9t6xpmKYi9+FNU61GeihhoO2qQRIKoqGZtdud
1DvJ+4FSlNslwWfhWaH9HCskDRvKryDWRBxqF1HIB7CREd8Jaj+/vDg53j/o
Ntahb3V0DmVBsy2PdmOdWVv6alrV3FnXNrX2z/22kFDvD5CeJ1/C9jypReJI
4Sy+Wf5Xzpc/oSkBcRDkkIHCKK8U08rVwmepm8JwKRvP/yRhWyDAjnCIJLYP
/+o19rHG2l8hs+ble8umtbkIHdrvv/8eXvXzl1cm7BNLQ2rvYHwgfW7fTMk+
P2Hw4/6RbGJOzUd2mBlqIwUz2d83F/+KJ891v3mkwPFjn2IcrWzE0XVVTJET
3o/stfunp8f7+0ol1HdTkxYVN9a/w+O4Mz0NLWCGiUHodPPhgT7Ztsr5bDwZ
T/S5dLbx7DeDwTfyIGgCo3RAbLXJh/P9p+5oMpmPDuaHh6PD/ePJ6HR2dDQ6
PTp5Nj89SE/TwzBfrx/GD7cNTh6s/X0E9HGsFihT853u9KZYCJykttN+nUsu
5b0J43TstgjhRNk8O07nk9noYHbsRoeHB5OR3Z+djObH82fPTp/Z4/1MV373
cypHCERI3B+1Ez4wanK0/8BbAguSWPr+tw/oJ7xpdFEDHpAe7R+MDp5d7T+d
Pj2eHp78x87sW5WEhx/k32+Gd8XV6wH8RaTV/ClCenb0oBRka+N/JoXeUwk7
neXEydibptXpkWi7ysfRjXnYNZuxytuLiw9eOOgofHhQytpN+YxYoxVpIfUp
6RxM9k/h2OPJ4dEnTOnHsKSHbWbVTnttpR9kLcfz7PDg2O2PTk4n+6PDg/35
6DR9hth8+Ox0f39//mwyedbnilLmSj/lbp8X1Mmn5IO0ypPOD0vpR7C0KLvh
X0o4k78B4ewY1tItec3j/4htjT8lv5/nP/t/a1hHR/ufSnGvPyaaHz3HJUFI
dyL9QDZPPxHk5f2eoI0wT3/ke7k54Yq9ZsG7MlWRgXSY+N64Hqn+eHKWfBAM
CWh56dJW7ho8575SFs4KAxjHgzo8yMsq072HW+bc7WQluV64MvQNettq/d1r
89oCL+ZV6xMA6ar2oT3T+nB5pb+lTMhc1YCRvGIjFG3TWJ524c6bnoKz4Yxl
snN2fXtoi9uAkVn2gLBu9nDD9jAPwZXhgLIBTo3dEh7v87pvjqeCttkquCeO
q92zmnePbm83g7eHke5CZTkM/XpLQ69g9Td042tUDr0RfbT9xLwNpzK5dYbX
DSDz1JR7Fq8u4lmy+69elmmV6U2J/rqmZpaXtt5gRGcId0foMdifSifNL6B8
2RvUseF6UWjRcOu0KKTnJjYZD6xyLdzAdY4NAcNTsJxONP/FwURbWA8enpPD
b2aHBTm17/t7S4Tn78Jp9bexi3LeNfBR3bFrokdgrZ5gE6qfXQwbPS2vH2x5
57mJLe/PhM5n2ded654apT6HH9Wbe/dDCFGHavGyX0irDgdx2Se5tekmtqXZ
NLkWzkNZEo7cdLsTKh3W+NIvYqUpB5Klf9NtYYgowgWWIKNeT4GHT3mG2ty9
87DOoWrVggsyG+rNSKcHX2HYdcXS0HfNtKuvLvdYZ14OzcUZ/HNiXJNyW/X8
7pWLu0b4BnkA474OJ4mz3TVONaJQQXIJCyPP+ldXtL/SRR7x46n5JaTO8PTE
fFnba226brd9PuUGYYtarg2eaitnKx94WULL6YhGUwz62DYxK21P77qJuLhe
9RTe8YXYYCeDswdNTbPAwdi8YEchBD2eV9ZO3vbkfyPVPKMCP5gwTl/naeiF
P/KPt++ejs2XvFfGA0Il63J5Ow5VvzGH/DaFFVZ+YeYcKUGLp2Gm5urlv1/J
qKNxODnSd8kYlsK9WURbvck6pY7xXv1P9rxTbajM21oaog8t+c2n77JijS8/
cgtVLa9kWzMI+blYMsUsN2n3nuuBwJAfCld/ZCJeIkjZhS5cdq33RJg0rByp
qox5nd84c7Zsy8w7OMrLOr8xv8oLHhz6Rcs7JuZn8JWKj+mDb2kjcLD4L09+
6NU9315f6zkzbTPPkfJ49GVszkqxqde2vuGFDRriwsoFHjMDOpIuqxDSS8LM
BjBgb5z1ebGR1Pect6biDaFLRhX8vnMxAuv6FbN/uHqHSPZgQjbd9bh4KY24
wYLftZFdBJHLjXMrnhJZ5mUmJz66k85dQu0f851h5aaognmzly24XU/nyxYk
tVdsRjz/AOXzQFgXfUI3ZwAqqWUwyBuNYgtXrAyL71E8ixvD0PYYGP3y1UMJ
38dm60rs1jIehvPrAdcNzaZqA/qxGag3gFFJ/8Qn85P04vfw1fYx5KsnwneP
8slRVzuHJrPenTTT3eYKkIaDtqFiR0c7Keqj6+qfyglngK2RO9ol6Rf53GnD
m41/wbqf6AQOHhu5e8uU0rt1tr1auqjW0Kzek2KKU3lJB1tuleqq5WAfNVRs
uqO5MKkmXUSrbcs8uvSLFxeXI+2mJzvnkukrPDoPN5DtlVSOpMX1lO66anRn
amfXQ+8BIO/ogd3exRDd+nh5Za/9dp+FG9qPKd7n+Kta7ipRg70cGuT+VWwt
y/YOHZaIgKR5Tlw3xnjsGCKg3YQ9lC10xjrkGGKpJ9DZkacz4+922fPg3ZtM
PYy/5N0QyY8PYlq59mD7KGVtN5yEN9a3Ww8fx8OsghhKBh3v/xBOm8azzsnD
H8eLZMEI8WmE97q9O3ObKuxgdYaZdIoMG2cPkhbRw2VFq7wJrpeE5b510d1P
PZT7YWde9+fagv+nC0FmVUuZMUtFE/2IAB7pREmP5uOeMXfGi2gU7vFz126j
h9etIs1HimDWtIREdgbXLMVmznSXtMDnV8gxfM7Dhcomgqf8fzO4Wu8EHu4f
mkfQGsITMtFjggvbHYaVsQAtKuNqxvNmSfB4GNdq8xmBckleNoN1d1Qidrsa
NdUok+Pd/w0DjNnbwkMAAA==

-->

</rfc>