Re: H2 Implementation Debug State URI

> On 5 Aug 2016, at 09:01, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> 
> So at the very least this needs to be firmly turned off by default
> and have a major warning posted on the enabling button.

You’re going to love my time machine: https://github.com/python-hyper/draft-http2-debug-state/commit/532c5315c8b8ab28993eff69e232dd261096359d <https://github.com/python-hyper/draft-http2-debug-state/commit/532c5315c8b8ab28993eff69e232dd261096359d>

I agree with you, and there’s some extensive conversation going on on the GitHub page about the way this interacts with proxies. In the short term, draft-01 will contain a strong admonition not to use the “hpack" key on uncontrolled networks.

The longer term question is about how to deal with the fact that a misbehaving H2 connection could be the result of the H2 state in any of the hops on the connection. For example, if you have a connection that goes: client -> forward proxy A -> reverse proxy B -> origin server, and all those hops are H2, you really need to see H2 state in *all* of them to understand what the problem might be. However, the well-known URI doesn’t allow for that kind of debugging without requiring the awkward step of needing proxies to rewrite the response body to include their own data.

A frame might be better, but then we lose some of the introspective power, as well as somewhat increasing the overhead of an implementation deploying this kind of support. Certainly it’s much harder to see the value of it when you can’t easily demo in a browser.

Cory