Re: H2 Implementation Debug State URI

This is a nice debugging asset! But looking forward to a more generic
mechanism that could be used leveraged by application servers and by
web-applications, it could be possible to just leverage the "Forwarded"
HTTP extension (RFC 7239).

We do something like that for some bits and pieces :
https://www.shimmercat.com/en/info/articles/forwarded-header/

On Thu, Jul 28, 2016 at 4:00 PM, Stefan Eissing <
stefan.eissing@greenbytes.de> wrote:

> 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 <cory@lukasa.co.uk>:
> >
> > 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
>
>
>


-- 
Alcides Viamontes E.
Chief Executive Officer, Zunzun AB
(+46) 722294542
(www.shimmercat.com is a property of Zunzun AB)