rschmitt commented on PR #547: URL: https://github.com/apache/httpcomponents-core/pull/547#issuecomment-3185925799
Copying a comment from #543: > No amount of trickery can make the protocol handler aware of the opposite endpoint's intent to not honor the protocol requirements with regards of the connection persistence, especially when using TLS to negotiate the connection closure. It can get lucky and read the end of stream over a plain connection but this is just luck. I think here, "the protocol requirements with regards of the connection persistence" refers to my test server in `TestConnectionClosureRace`, which closes the connection without sending a `Connection: close` header. I did this deliberately in order to simulate stale connection reuse and provoke race conditions, but I was reminded today that all of the connection persistence headers are [explicitly prohibited](https://httpwg.org/specs/rfc9113.html#ConnectionSpecific) by HTTP/2 and HTTP/3. This means that what is happening in my reproducer is actually pretty representative of what happens on an HTTP/2 connection, in the sense that recognizing the closure of the connection requires the client to read beyond the last byte of the current response. Instead of sending a `connection: close` header in the response itself (which would be considered malformed, per the spec), the server would send a separate `GOAWAY(last_stream_id, NO_ERROR)` frame. It's important to handle this case, particularly as we move towards supporting HTTP/2 multiplexing: I'd say that h2 connection reuse should _always_ be completed through the event loop, so that we don't open a new stream until we know that an unprocessed `GOAWAY` frame isn't sitting in the recv buffer. (We could also check the flow control numbers for the connection and make sure the write end isn't already completely saturated.) We may also want to turn `TestConnectionClosureRace` into either an integration test or an example class. I'm reluctant to write a version of it that actually _asserts_ anything, which seems like a recipe for a flaky test, but just keeping it around as an example class would be really useful for future investigations. -- 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
