Add new HTTP/2 frame

[PiotrSikora]

Currently proposed /.well-known/h2interop/state URL:

• can pass through proxies that don't support this feature... although, it's not clear which of N intermediate proxies (not all respect Max-Forwards) would generate response to this query,
• seems limited to on-demand (manual?) inspection,
• changes state of the connection,
• can be queried and displayed in a browser.

HTTP/2 frame:

• is hop-by-hop,
• can be used for passive sanity checks on each frame and/or request,
• doesn't change state of the connection,
• can be displayed in a browser (chrome://net-internals, etc.).

The main advantage of handling this at the HTTP/2 level is the ability to add passive sanity checks and/or alerts, i.e. peers could indicate (via SETTINGS frame) that they want to receive this frame with the window size the other peer believes is still available (before each DATA frame or before frame with the END_STREAM flag), when sending window is exhausted, etc.

/cc: @bradfitz @louiscryan

[Lukasa]

Thanks for this suggestion! My original reluctance to do this using a HTTP/2 frame was based on a few thoughts.

Firstly, this may produce quite a lot of data. A new HTTP/2 frame is usually not flow-controlled (you can't flow-control a frame unless it's a negotiated extension), which means that it's possible to snarl up a connection by getting a peer to generate a lot of debugging information. That was a major part of the reasoning for moving to a request/response model for displaying the information: it allows us to ensure that the debugging information isn't higher priority than anything else.

Second, a new frame requires both parties to opt-in to the behaviour. For example, you have said:

can be displayed in a browser (chrome://net-internals, etc.).

However, I don't think that Chrome will implement support for this functionality. The Google folks I chatted to last week didn't express much interest, anyway. That potentially causes problems: with the URI all clients can always retrieve this data, but with the frame they cannot.

Of course, this is still a bit true if we switch to OPTIONS (see #7) rather than GET (though less-so than the custom frame).

Altogether, I felt like the custom frame was a bigger implementation inconvenience than the well-known URI, especially as I'm not at all confident of getting the HTTPbis to take up this draft as a WG document, which means it will forever be at best an informational draft. I really don't love the idea of having a lot of stacks implementing an extension frame type that is defined in a document the HTTPbis doesn't want to standardise.

[bradfitz]

Let's consolidate conversation in #7. It's basically the same topic.