rschmitt commented on PR #547: URL: https://github.com/apache/httpcomponents-core/pull/547#issuecomment-3190313952
> A well behaved endpoint should not just write out GOAWAY(NO_ERROR) and immediately drop connection. And a well-behaved _client_ should not attempt to reuse a connection on which it has already received a `GOAWAY` frame. I haven't looked at the h2 duplexer code to see how this is handled, but my point is that the `StaleCheckCommand` approach is actually a really good strategy for connection reuse: it allows the client to perform an additional read _on the connection itself_ before reusing a connection, which allows connection closure (at whatever layer of the protocol stack) to be processed. Overall, I see this as a more modern approach. The HTTP 1.x connection headers are legacy stuff from the '90s, and we shouldn't rely on them exclusively to prevent stale/closed connection reuse. I actually think that `StaleCheckCommand` could replace `PingCommand` as the connection validation strategy for HTTP/2, since it's almost as reliable but way faster since the caller doesn't have to wait for a round-trip over the network. > I looked at various ways of improving the logic in the stale connection command but could not figure out anything useful on top of what we already have. I do not think the check can be made 100% reliable and this is probably as good as it gets for now. Do you want me to commit the change-set, keep it open or drop it? I'm happy with the version of this change I tested locally. The client-server dyad is a distributed system, so connection closure race conditions are always a possibility, but I think the changes I described earlier fix the purely _internal_ race condition within the client. I'll submit a branch with those changes, and any further simplifications. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
