Re: H2 Implementation Debug State URI

[Stefan Eissing <[e-mail]>]

Thanks, Cory!. Apache will offer this as a configurable handler and I will make a beta available via github soon. Currently outputs lacks individual streams and looks like this:
{
  "settings": {
    "SETTINGS_MAX_CONCURRENT_STREAMS": 100,
    "SETTINGS_MAX_FRAME_SIZE": 16384,
    "SETTINGS_INITIAL_WINDOW_SIZE": 65535,
    "SETTINGS_ENABLE_PUSH": 1
  },
  "connFlowIn": 2147483647,
  "connFlowOut": 12571993,
  "sentGoAway": 0,
  "in": {
    "requests": 63,
    "resets": 0, 
    "frames": 134,
    "octets": 3831
  },
  "out": {
    "responses": 62,
    "frames": 130,
    "octets": 13754
  },
  "push": {
    "cacheDigest": "AQib_wA",
    "promises": 1,
    "submits": 1,
    "resets": 0
  }
}

-Stefan

> Am 28.07.2016 um 14:38 schrieb Cory Benfield <[e-mail]>:
> 
> All,
> 
> During the HTTP workshop earlier this week, several HTTP/2 implementers expressed a desire to extract information about the state of the H2 connection from the perspective of their peer. This would be extremely useful when developing, debugging, and testing implementations: given that HTTP/2 is so highly stateful the vast majority of interoperability issues come from implementations disagreeing about what the state of the connection is (usually flow control windows!).
> 
> Brad Fitzpatrick and I ended up prototyping a sample approach for getting this information out of server implementations, based on issuing a GET request to a specific well-known URI. This GET would return a JSON document that contains various different pieces of information from inside the implementation, such as window sizes and stream states. In addition, to help debug flow control concerns, the response headers also include information about flow control windows (because if a server believes it is blocked behind flow control it can’t send the JSON document, but it can send the response headers). Examples of this behaviour are available at https://http2.golang.org/.well-known/h2interop/state and https://shootout.lukasa.co.uk/.well-known/h2interop/state.
> 
> The consensus amongst the implementers we spoke to were that this was a good idea, and it would be good to collaborate on the information that should be exposed here. For most HTTP/2 implementers one of the most natural ways to collaborate on something like this is to use an Internet Draft. For that reason, I have submitted the outline of a draft that essentially defines what Brad and I have already done. You can find this draft here: https://tools.ietf.org/html/draft-benfield-http2-debug-state-00
> 
> I have no expectation that this will become a WG document. However, I’d like to bring it to the attention of the working group to ensure that as many implementers as possible can provide feedback on whether this kind of approach is valuable or not, and what information they’d like made available in this kind of mode.
> 
> For anyone who wants to contribute, raise issues, or otherwise help with the draft, it is hosted on GitHub: https://github.com/python-hyper/draft-http2-debug-state. Issues and pull requests are more than welcome, as is feedback on this list.
> 
> Thanks,
> 
> Cory