Add downstream support for proxies

[louiscryan]

For proxies how could a proxy incorporate the down-stream state into this schema. E.g.

streams : {
   <stream id> : {
         ....
        downstream : {
              <conn level info with redaction for security>
              streams : {
                 <downstream id - possibly obfuscated> : {
                       <recursion!>
                 }
            }
       }
}

All of this info being subject to security paranoia etc

From @Lukasa

"As to proxies, I think realistically this needs to be hop-by-hop. It doesn't make sense to dump the H2 state for the server if you have a proxy actively doing e.g. connection coalescing. If the proxy is transparent doing nothing, though, then it can safely pass the request through. Maybe servers should refuse to serve this response if X-Forwarded-For is present?"

I agree it's impractical to recursively dump state when connection coalsecing is occurring. This feature probably only makes sense when restricted to a single stream. Perhaps we could allow the trigger to specify a stream and only then would the recursion occur. E.g

.well-known/h2interop/state?stream=X&depth=

Also I don't think theres such a thing as a truly transparent h2 proxy from a flow-control perspective.

For folks using big Cloud load balancers like GCLB & ECLB they won't have enough control over the proxy to be able to reliably diagnose issues with the h2 backends without some end-to-end support

[louiscryan]

Its also worth pointing out that when walking a stream over a set of proxies that each proxy node will have two views of the state. For example

A --> B (proxy) -->C

there are

A's view of B (locally available without calling the well-known endpoint) B's view of A (fetched via well-known) B's view of C (see above) C's view of B (recursively fetched via well-known)

Given that any one of these layers may be introducing a problem the spec should account for the duality

[Lukasa]

I agree it's impractical to recursively dump state when connection coalsecing is occurring. This feature probably only makes sense when restricted to a single stream. Perhaps we could allow the trigger to specify a stream and only then would the recursion occur. E.g

.well-known/h2interop/state?stream=X&depth=

So I don't think this works either. If proxies are coalescing then they have to map this stream one side to the other, which is quite a lot of work: I suspect most proxies will simply want to disable this functionality rather than support such a query.

Also I don't think theres such a thing as a truly transparent h2 proxy from a flow-control perspective.

There can be, so long as the h2 proxy doesn't interfere with traffic. For example, intercepting proxies that just want to drop debug data (i.e. that don't write to the streams) can safely pass data through without difficulty.

For folks using big Cloud load balancers like GCLB & ECLB they won't have enough control over the proxy to be able to reliably diagnose issues with the h2 backends without some end-to-end support

I agree, but unfortunately that's not likely to come. I don't think the big proprietary implementations will ever implement this spec, regardless of how it's done: they just have no particular interest in doing so.

However, I agree that we need to come up with some idea of what proxies should do. At best right now I think the best approach is that proxies should either respond for themselves or 404: I'm still not convinced that they can safely do anything else.

[louiscryan]

@piotrsikora

For typical off-the-shelf proxies (nginx, nghttpx etc) they already have to do the work of tracking the relationships upstream and downstream so I'm not sure this is an issue.

Agreed that there can be transparent proxies, I'm just not sure they're really likely to exist. I think its far more likely folks will use the ones I mentioned above which may be close to transparent in default configurations but flow-control divergence upstream and downstream will still be a source of headaches.

As for big Cloud vendors while I can't say they will support it I can say that the lack of such support end-to-end makes it very hard to debug issues that their customers will face when traffic flows through many layers of proxy. This is speaking from hard, painful experience. I've pinged the GCLB folks to come and weigh in here as well as Piotr who does nginx work in this area.

[louiscryan]

One way to solve this issue is to allow the remote side to include a URI that allows the downstream state(s) to be de-referenced. E.g.

http://myproxy/.well-known/h2interop/state?connection=opaque-connection-id

A nice property of this technique is that implies a proxies ability to expose the debug state to an agent that is not the consumer of the connection.

One concern that has come up is whether the use of HEADERS is going to be reliable in all cases and whether we need a DEBUG frame to work around things like concurrent stream limits. This mechanism can be used to work around that

[Lukasa]

So I think we need to answer #7 before we can safely move this forward.