Repository navigation
Add downstream support for proxies #2
Description
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
Activity
louiscryan commentedon Jul 28, 2016
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 commentedon Jul 29, 2016
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.
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.
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 commentedon Jul 29, 2016
@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 commentedon Jul 29, 2016
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 commentedon Jul 30, 2016
So I think we need to answer #7 before we can safely move this forward.