draft-benfield-http2-debug-state-01.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.0.28 -->

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

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-benfield-http2-debug-state-01" category="info">

  <front>
    <title abbrev="HTTP2-debug-state">HTTP/2 Implementation Debug State</title>

    <author initials="C." surname="Benfield" fullname="Cory Benfield">
      <organization>Hewlett Packard Enterprise</organization>
      <address>
        <email>cory@lukasa.co.uk</email>
      </address>
    </author>
    <author initials="B." surname="Fitzpatrick" fullname="Brad Fitzpatrick">
      <organization>Google, Inc.</organization>
      <address>
        <email>brad@danga.com</email>
      </address>
    </author>

    <date year="2016" month="August" day="10"/>

    <area>Applications and Real-Time Area</area>
    <workgroup>Hypertext Transfer Protocol Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document defines a standard format and well-known URI for HTTP/2 server
implementations to expose their internal state for the purposes of debugging
and interoperability work.</t>



    </abstract>


  </front>

  <middle>


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

<t>The HTTP/2 <xref target="RFC7540"/> specification provides an alternative framing layer for
the semantics of HTTP/1.1 <xref target="RFC7231"/>. This alternative framing layer includes
substantially greater quantities of state to be stored by all implementations.
Disagreements on the state of the connection are the cause of the vast majority
of interoperability errors in HTTP/2 implementations.</t>

<t>In general it is not possible for implementations to query the internal state
of their peer, and those implementations that do expose their internal state do
it using a number of different interfaces, in different places, and in
different formats. This makes it hard to debug interoperability problems,
particularly when those problems arise on the open web with implementations
that have unknown configuration and that may not identify themselves clearly.</t>

<t>This document defines a standard format and well-known URI for HTTP/2 server
implementations to make their internal state available for introspection. This
allows both new and established implementers to do more effective testing of
their implementations, as well as to enable them to more effectively diagnose
and report subtle bugs in both their own and other implementations.</t>

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

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

<t>An implementation that wishes to support the HTTP/2 debug state information
does so by publishing a JSON document at a well-known URI (<xref target="RFC5785"/>):
specifically, at .well-known/h2/state. This JSON document reveals aspects of
the state of the specific HTTP/2 connection as seen by the implementation in
question at the time of response generation.</t>

<t>This JSON document is represented as a single JSON object with multiple keys.
The object has several mandatory keys, as well as several optional ones. The
fields are outlined below.</t>

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

<t>The “version” key in the state object is associated with a string carrying the
version of the debug output specification the debug output conforms to. For
an implementation that supports this draft specification, the output must be
“draft-01”.</t>

<t>Sample output:</t>

<figure title="Example output for version key" anchor="example-version"><artwork><![CDATA[
"version": "draft-01"
]]></artwork></figure>

</section>
<section anchor="settings" title="Settings">

<t>The “settings” key in the state object is associated with a JSON object that
contains the remote implementation’s active settings. These are the settings
that are actually in force for the connection at this time. This means that
if the implementation has emitted a SETTINGS frame but has not yet received an
ACK, the changes in that SETTINGS frame MUST NOT be reflected in the object.</t>

<t>Each setting is published along with its value. The name of each setting MUST
be the same as its name in <xref target="RFC7540"/> Section 6.5.2: for example,
“SETTINGS_ENABLE_PUSH”. The values MUST be sent as JSON integers.</t>

<t>An implementation MAY omit a setting from this object if it has never been
emitted by the implementation. In this situation it should be assumed that the
default value is in force.</t>

<t>A conforming implementation MUST emit this field.</t>

<t>Sample output:</t>

<figure title="Example output for settings key" anchor="example-settings"><artwork><![CDATA[
"settings": {
  "SETTINGS_MAX_CONCURRENT_STREAMS": 250,
  "SETTINGS_MAX_FRAME_SIZE": 1048576,
  "SETTINGS_MAX_HEADER_LIST_SIZE": 1048896
}
]]></artwork></figure>

</section>
<section anchor="peer-settings" title="Peer Settings">

<t>The “peerSettings” key in the state object is associated with a JSON object
that contains the remote implementation’s view of the local implementation’s
settings. These are the settings that are actually in force for the connection
at this time.</t>

<t>The value of this key is exactly symmetrical with the value of the “settings”
key: see <xref target="settings"/> for more.</t>

<t>A conforming implementation MUST emit this field.</t>

<t>Sample output:</t>

<figure title="Example output for peerSettings key" anchor="example-peer-settings"><artwork><![CDATA[
"peerSettings": {
    "SETTINGS_HEADER_TABLE_SIZE": 4096,
    "SETTINGS_ENABLE_PUSH": 1,
    "SETTINGS_INITIAL_WINDOW_SIZE": 6291456,
    "SETTINGS_MAX_FRAME_SIZE": 16384,
    "SETTINGS_MAX_CONCURRENT_STREAMS": 1000
}
]]></artwork></figure>

</section>
<section anchor="outbound-window" title="Outbound Flow Control Window">

<t>The “connFlowOut” key in the state object is associated with a JSON integer
that reflects the remote peer’s outbound connection window size. This
represents the number of flow controlled bytes the remote implementation
believes it can emit before the entire connection is blocked behind flow
control.</t>

<t>A conforming implementation MUST emit this field.</t>

<t>Sample output:</t>

<figure title="Example output for connFlowOut key" anchor="example-conn-flow-out"><artwork><![CDATA[
"connFlowOut": 15724175,
]]></artwork></figure>

</section>
<section anchor="inbound-window" title="Inbound Flow Control Window.">

<t>The “connFlowIn” key in the state object is associated with a JSON integer
that reflects the remote peer’s inbound connection window size. This represents
the number of flow controlled bytes the remote implementation believes it can
receive before the entire connection is blocked behind flow control.</t>

<t>A conforming implementation MUST emit this field.</t>

<t>Sample output:</t>

<figure title="Example output for connFlowIn key" anchor="example-conn-flow-in"><artwork><![CDATA[
"connFlowIn": 65535,
]]></artwork></figure>

</section>
<section anchor="streams" title="Streams">

<t>The “streams” key in the state object is associated with a JSON object
containing state about all the active streams on the connection. A stream MUST
be represnted in this JSON object if it is in any state other than IDLE or
CLOSED.</t>

<t>This JSON object has keys that are the stream IDs for the active streams. Each
key has an object associated with it, with the following keys:</t>

<t><list style="symbols">
  <t>“state”: This key maps to a string value representing the stream state.
The stream states are represented as all-caps ASCII text with all parentheses
stripped and spaces replaced with underscores. For example, “OPEN” or
“HALF_CLOSED_LOCAL”. This field MUST be present.</t>
  <t>“flowIn”: The remote peer’s inbound stream window size as a JSON integer.
This represents the number of flow controlled bytes the remote implementation
believes it can receive on this stream before this stream is blocked behind
flow control. This field MUST be present.</t>
  <t>“flowOut”: The remote peer’s outbound stream window size as a JSON integer.
This represents the number of flow controlled bytes the remote implementation
believes it can send on this stream before this stream is blocked behind flow
control. This field MUST be present.</t>
  <t>“dataIn”: The number of bytes of data the remote implementation has
received on this stream. This excludes padding bytes. This field MAY be
present, but is optional.</t>
  <t>“dataOut”: The number of bytes of data the remote implementation has sent
on this stream. This excludes padding bytes. This field MAY be present, but
is optional.</t>
  <t>“paddingIn”: The number of padding bytes the remote implementation has
received on this stream. This excludes data bytes. This field MAY be present,
but is optional.</t>
  <t>“paddingOut”: The number of padding bytes the remote implementation has
sent on this stream. This excludes data bytes. This field MAY be present, but
is optional.</t>
  <t>“queuedData”: The number of bytes of data the remote implementation has
available to send, but has not yet sent. These bytes may be blocked behind
flow control or priority information: the value of the “flowOut” field can
be used to distinguish between these two cases. This field MAY be present,
but is optional.</t>
  <t>“created”: A timestamp indicating when the peer believes the stream first
transitioned out of the idle state (see <xref target="RFC7540"/> Section 5.1). This time
stamp must be in the form of a Unix time stamp: that is, a number
representing the number of seconds since 00:00:00 Thursday 1 January 1970
UTC. This number may have any number of decimal digits. This field MAY be
present, but is optional.</t>
</list></t>

<t>A conforming implementation MUST emit this field, but MAY omit any of the
optional sub-fields.</t>

<t>Sample output:</t>

<figure title="Example output for streams key" anchor="example-streams"><artwork><![CDATA[
"streams": {
  "5": {
    "state": "HALF_CLOSED_REMOTE",
    "flowIn": 65535,
    "flowOut": 6291456,
    "dataIn": 0,
    "dataOut": 0,
    "paddingIn": 0,
    "paddingOut": 0,
    "created": 1470835059.619137
  },
  "7": {
    "state": "OPEN",
    "flowIn": 65535,
    "flowOut": 6291456,
    "queuedData": 59093,
  }
},
]]></artwork></figure>

</section>
<section anchor="hpack" title="HPACK">

<t>The “hpack” key contains information about the HPACK compression state for
the connection. It maps to a JSON object that represents this compression
state.</t>

<t>This JSON object contains the following fields:</t>

<t><list style="symbols">
  <t>“inboundTableSize”: The current size of the HPACK dynamic header table
for the headers emitted by the local implementation, as an integer. This
field MUST be present.</t>
  <t>“outboundTableSize”: The current size of the HPACK dynamic header table
for the headers emitted by the remote implementation, as an integer. Note
that this value MUST include the headers added to the compression context as
part of serving this response. This field MUST be present.</t>
  <t>“inboundDynamicHeaderTable”: The entries added to the HPACK dynamic
header table by the local implementation. This is formatted as a JSON array
of two-element JSON arrays, the first element of which contains the header
name and the second element of which contains the header value. This field
MAY be omitted.</t>
  <t>“outboundDynamicHeaderTable”: The entries added to the HPACK dynamic
header table by the remote implementation. This is formatted in the same
manner as “outboundDynamicHeaderTable”. This field MAY be omitted.</t>
</list></t>

<t>A conforming implementation MAY omit this field. If it does include this field,
it MAY omit any optional sub-fields.</t>

<t>Sample output:</t>

<figure title="Example output for hpack key" anchor="example-hpack"><artwork><![CDATA[
"hpack": {
    "inboundTableSize": 340,
    "inboundDynamicHeaderTable": [
        [
            "accept-encoding",
            "gzip, deflate, sdch, br"
        ],
        [
            "upgrade-insecure-requests",
            "1"
        ],
        [
            "cache-control",
            "max-age=0"
        ],
        [
            ":authority",
            "shootout.lukasa.co.uk"
        ]
    ],
    "outboundTableSize": 137,
    "outboundDynamicHeaderTable": [
        [
            "content-type",
            "application/json"
        ],
        [
            "server",
            "TwistedWeb/16.3.0"
        ]
    ]
}
]]></artwork></figure>

</section>
<section anchor="sent-goaway" title="Sent GoAway">

<t>The “sentGoAway” field tracks whether or not a GOAWAY frame (<xref target="RFC7540"/>
Section 6.8) has been sent on the connection by the remote implementation. The
value of this field is boolean.</t>

<t>A conforming implementation MAY omit this field.</t>

<t>Sample output:</t>

<figure title="Example output for sentGoAway key" anchor="example-sent-go-away"><artwork><![CDATA[
"sentGoAway": false,
]]></artwork></figure>

</section>
<section anchor="additional-fields" title="Additional Fields">

<t>In addition to these fields, implementations MAY add their own debugging
information, as appropriate, to the JSON object. These MUST be keyed off keys
other than the ones defined in this document. For example, some implementations
are known to expose the number of threads they currently have active in the
“threads” field.</t>

</section>
</section>
<section anchor="debug-headers" title="Debug Headers">

<t>One of the most common issues when implementing HTTP/2 is to have problems with
flow control windows. This is why the “connFlowOut” (<xref target="outbound-window"/>) and
“connFlowIn” (<xref target="inbound-window"/>) fields are defined in the JSON document.</t>

<t>However, it’s possible that the two implementations disagree on the size of
this window, and that the server believes that it cannot send the response body
because it’s blocked behind flow control. For this reason, a small amount of
debugging data MUST be inserted into the response headers for this JSON
document. This ensures that it is possible for implementations to discover that
they have inadvertently blocked the debug response behind flow control, and to
take action to widen the flow control window so that the response can be
delivered.</t>

<t>The following header fields MUST be emitted by implementations.</t>

<section anchor="flow-in" title="Flow In">

<t>The “conn-flow-in” header field contains the size of the remote
implementation’s inbound flow control window. The field value contains only the
size of that window in octets. This MUST be calculated the same way that the
implementation calculates “connFlowIn” (<xref target="inbound-window"/>).</t>

</section>
<section anchor="flow-out" title="Flow Out">

<t>The “conn-flow-out” header field contains the size of the remote
implementation’s outbound flow control window. The field value contains only
the size of that window in octets. This MUST be calculated the same way that
the implementation calculates “connFlowOut” (<xref target="outbound-window"/>).</t>

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

<section anchor="hpack-state" title="HPACK State">

<t>For a single-hop HTTP/2 connection there is no risk in exposing the HPACK state
to the client, as the only entity that can possibly have affected the HPACK
state is the client itself.</t>

<t>However, once intermediaries are considered this stops being true. If any
intermediary is performing connection coalescing, the HPACK state will almost
certainly include entries inserted into the dynamic table by or for multiple
clients. Exposing this state will put the security and privacy of those other
clients at risk.</t>

<t>For this reason, if it is at all possible that a server implementing this
specification may have an intermediary on a connection between itself and a
client, the server MUST NOT emit the “hpack” key or any of its sub-fields. It
is only safe to emit this key in controlled environments.</t>

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

<section anchor="well-known-uri" title="Well-known URI">

<t>This document establishes a single well-known URI, with the suffix “h2/state”.</t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC7540' target='http://www.rfc-editor.org/info/rfc7540'>
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author initials='M.' surname='Belshe' fullname='M. Belshe'><organization /></author>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t><t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t></abstract>
</front>
<seriesInfo name='RFC' value='7540'/>
<seriesInfo name='DOI' value='10.17487/RFC7540'/>
</reference>



<reference  anchor='RFC2119' target='http://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='RFC5785' target='http://www.rfc-editor.org/info/rfc5785'>
<front>
<title>Defining Well-Known Uniform Resource Identifiers (URIs)</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<author initials='E.' surname='Hammer-Lahav' fullname='E. Hammer-Lahav'><organization /></author>
<date year='2010' month='April' />
<abstract><t>This memo defines a path prefix for &quot;well-known locations&quot;, &quot;/.well-known/&quot;, in selected Uniform Resource Identifier (URI) schemes.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5785'/>
<seriesInfo name='DOI' value='10.17487/RFC5785'/>
</reference>



<reference  anchor='RFC7231' target='http://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>




    </references>



<section anchor="defined-fields" title="Defined Fields">

<t>This appendix contains tables of all defined fields, along with their field
names, field value type, optionality, the versions in which they appear, and
what section defines them.</t>

<t>For fields whose values are objects, there are additional tables defining the
fields in those sub-objects, with the same information.</t>

<t>This can be used as a quick reference point.</t>

<texttable title="Top-level Fields" anchor="top-level-fields">
      <ttcol align='left'>Field Name</ttcol>
      <ttcol align='left'>Field Type</ttcol>
      <ttcol align='left'>Optional?</ttcol>
      <ttcol align='left'>Versions</ttcol>
      <ttcol align='left'>Section</ttcol>
      <c>version</c>
      <c>String</c>
      <c>No</c>
      <c>draft-01 ..</c>
      <c><xref target="version"/></c>
      <c>settings</c>
      <c>Object</c>
      <c>No</c>
      <c>draft-01 ..</c>
      <c><xref target="settings"/></c>
      <c>peerSettings</c>
      <c>Object</c>
      <c>No</c>
      <c>draft-01 ..</c>
      <c><xref target="peer-settings"/></c>
      <c>connFlowOut</c>
      <c>Number</c>
      <c>No</c>
      <c>draft-01 ..</c>
      <c><xref target="outbound-window"/></c>
      <c>connFlowIn</c>
      <c>Number</c>
      <c>No</c>
      <c>draft-01 ..</c>
      <c><xref target="inbound-window"/></c>
      <c>streams</c>
      <c>Object</c>
      <c>No</c>
      <c>draft-01 ..</c>
      <c><xref target="streams"/></c>
      <c>hpack</c>
      <c>Object</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
      <c><xref target="hpack"/></c>
      <c>sentGoAway</c>
      <c>Boolean</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
      <c><xref target="sent-goaway"/></c>
</texttable>

<section anchor="settings-sub-fields" title="Settings Sub-Fields">

<t>This table lists the sub-fields of the “settings” and “peerSettings” values,
each of which is a single JSON object containing the following fields.</t>

<texttable title="settings and peerSettings Sub-Fields" anchor="table-settings-sub-fields">
      <ttcol align='left'>Field Name</ttcol>
      <ttcol align='left'>Field Type</ttcol>
      <ttcol align='left'>Optional?</ttcol>
      <ttcol align='left'>Versions</ttcol>
      <c>SETTINGS_HEADER_TABLE_SIZE</c>
      <c>Number</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
      <c>SETTINGS_ENABLE_PUSH</c>
      <c>Number</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
      <c>SETTINGS_MAX_CONCURRENT_STREAMS</c>
      <c>Number</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
      <c>SETTINGS_INITIAL_WINDOW_SIZE</c>
      <c>Number</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
      <c>SETTINGS_MAX_FRAME_SIZE</c>
      <c>Number</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
      <c>SETTINGS_MAX_HEADER_LIST_SIZE</c>
      <c>Number</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
</texttable>

</section>
<section anchor="streams-sub-fields" title="Streams Sub-Fields">

<t>This table lists the sub-fields of the “streams” value. The “streams” object is
defined more thoroughly in section <xref target="streams"/>. All of the fields defined here
appear in the objects that are the values of the “streams” sub-keys.</t>

<texttable title="Stream Sub-Fields" anchor="table-stream-sub-fields">
      <ttcol align='left'>Field Name</ttcol>
      <ttcol align='left'>Field Type</ttcol>
      <ttcol align='left'>Optional?</ttcol>
      <ttcol align='left'>Versions</ttcol>
      <c>state</c>
      <c>String</c>
      <c>No</c>
      <c>draft-01 ..</c>
      <c>flowIn</c>
      <c>Number</c>
      <c>No</c>
      <c>draft-01 ..</c>
      <c>flowOut</c>
      <c>Number</c>
      <c>No</c>
      <c>draft-01 ..</c>
      <c>dataIn</c>
      <c>Number</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
      <c>dataOut</c>
      <c>Number</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
      <c>paddingIn</c>
      <c>Number</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
      <c>paddingOut</c>
      <c>Number</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
      <c>queuedData</c>
      <c>Number</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
      <c>created</c>
      <c>Number</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
</texttable>

</section>
<section anchor="hpack-sub-fields" title="HPACK Sub-Fields">

<t>This table lists the sub-fields of the “hpack” value, each of which is a single
JSON object containing the following fields.</t>

<texttable title="HPACK Sub-Fields" anchor="table-hpack-sub-fields">
      <ttcol align='left'>Field Name</ttcol>
      <ttcol align='left'>Field Type</ttcol>
      <ttcol align='left'>Optional?</ttcol>
      <ttcol align='left'>Versions</ttcol>
      <c>inboundTableSize</c>
      <c>Number</c>
      <c>No</c>
      <c>draft-01 ..</c>
      <c>outboundTableSize</c>
      <c>Number</c>
      <c>No</c>
      <c>draft-01 ..</c>
      <c>inboundDynamicHeaderTable</c>
      <c>List of list of String</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
      <c>outboundDynamicHeaderTable</c>
      <c>List of list of String</c>
      <c>Yes</c>
      <c>draft-01 ..</c>
</texttable>

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

<t>We would like to thank the attendees of the 2016 HTTP Workshop in Stockholm for
their feedback on early prototype implementations of this debugging feature.</t>

</section>
<section anchor="changelog" title="Changelog">

<t>This appendix to be deleted by the RFC editor.)</t>

<t>Since -00:</t>

<t><list style="symbols">
  <t>Changed URI from <spanx style="verb">/.well-known/h2interop/state</spanx> to <spanx style="verb">/.well-known/h2/state</spanx>.</t>
  <t>Changed keys of “hpack” entry to all be camel-case, rather than snake-case.</t>
  <t>Added the “version” top-level key.</t>
  <t>Added the “created” sub-key to the “stream” objects.</t>
  <t>Added the “queuedData” sub-key to the “stream” objects.</t>
  <t>Added the “paddingIn” and “paddingOut” sub-keys to the “stream” objects.</t>
  <t>Added appendix documenting all field values.</t>
</list></t>

</section>


  </back>
</rfc>