HTTP/2 Implementation Debug State
draft-benfield-http2-debug-state-00

Abstract

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.

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 http://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 January 29, 2017.

Copyright Notice

Copyright (c) 2016 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 (http://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.

Table of Contents

• 1. Introduction
• 1.1. Notational Conventions
• 2. Debug Output
• 2.1. Settings
• 2.2. Peer Settings
• 2.3. Outbound Flow Control Window
• 2.4. Inbound Flow Control Window.
• 2.5. Streams
• 2.6. HPACK
• 2.7. Sent GoAway
• 2.8. Additional Fields
• 3. Debug Headers
• 3.1. Flow In
• 3.2. Flow Out
• 4. IANA Considerations
• 4.1. Well-known URI
• 5. Normative References
• Appendix A. Acknowledgements
• Appendix B. Changelog
• Authors' Addresses

1. Introduction

The HTTP/2 [RFC7540] specification provides an alternative framing layer for the semantics of HTTP/1.1 [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.

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.

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.

1.1. Notational Conventions

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

2. Debug Output

An implementation that wishes to support the HTTP/2 debug state information does so by publishing a JSON document at a well-known URI ([RFC5785]): specifically, at .well-known/h2interop/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.

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.

2.1. Settings

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.

Each setting is published along with its value. The name of each setting MUST be the same as its name in [RFC7540] Section 6.5.2: for example, “SETTINGS_ENABLE_PUSH”. The values MUST be sent as JSON integers.

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.

A conforming implementation MUST emit this field.

Sample output:

"settings": {
  "SETTINGS_MAX_CONCURRENT_STREAMS": 250,
  "SETTINGS_MAX_FRAME_SIZE": 1048576,
  "SETTINGS_MAX_HEADER_LIST_SIZE": 1048896
}

"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
}

"connFlowOut": 15724175,

"connFlowIn": 65535,

"streams": {
  "5": {
    "state": "HALF_CLOSED_REMOTE",
    "flowIn": 65535,
    "flowOut": 6291456,
    "dataIn": 0,
    "dataOut": 0
  },
  "7": {
    "state": "OPEN",
    "flowIn": 65535,
    "flowOut": 6291456
  }
},

"hpack": {
    "inbound_table_size": 340,
    "inbound_dynamic_header_table": [
        [
            "accept-encoding",
            "gzip, deflate, sdch, br"
        ],
        [
            "upgrade-insecure-requests",
            "1"
        ],
        [
            "cache-control",
            "max-age=0"
        ],
        [
            ":authority",
            "shootout.lukasa.co.uk"
        ]
    ],
    "outbound_table_size": 137,
    "outbound_dynamic_header_table": [
        [
            "content-type",
            "application/json"
        ],
        [
            "server",
            "TwistedWeb/16.3.0"
        ]
    ]
}

"sentGoAway": false,