New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net/http: failure in TestTransportConnectionCloseOnRequest due to reused client port #52450
Comments
This error message is fairly inscrutable to me (compare https://go.dev/wiki/CodeReviewComments#useful-test-failures). I think it is asserting that two consecutive calls that set Since the request sets That causes the server to close its write side of the connection immediately after it has written the response: If I understand correctly, the fact that the server closes the connection may avoid the TCP @neild, @ianlancetaylor, @bradfitz: could one of you confirm my understanding? (If the above is correct, then this failure mode is not specific to OpenBSD and we should fix the test rather than skipping it.) |
That test is testing that When false, the underlying connection should be reused for the two HTTP requests and they should both have the same body (the remote ip:port the http.Handler saw). When true, an underlying connection should never be reused. The server's behavior and So this error looks real to me. I don't think the test is bad. |
Note that this is a Transport test, in |
And the Transport code looks like it's fine: index f2d538b04a..e5ad44da3d 100644
--- a/src/net/http/transport.go
+++ b/src/net/http/transport.go
@@ -2136,6 +2136,9 @@ func (pc *persistConn) readLoop() {
// or we get an unexpected informational (1xx) response.
// StatusCode 100 is already handled above.
alive = false
+ if rc.req.Close {
+ panic("yup it was close")
+ }
}
if !hasBody || bodyWritable { =>
So it's definitely setting |
My hypothesis is that the test is creating two distinct TCP connections that happen to use the same outbound port. That's the connection to
|
Ah, okay. Yeah, I suppose that's possible. Low odds and kernels try to avoid it, which is why it probably shows up more on OpenBSD: different networking stack. Maybe they don't care/try there. We could make the http.Handler's repsonse body include the %p of the net.TCPConn as well. I'll try that out. |
Change https://go.dev/cl/401314 mentions this issue: |
greplogs --dashboard -md -l -e 'FAIL: TestTransportConnectionCloseOnRequest .*' --since=2021-07-01
2022-04-19T15:59:25-7a06243/openbsd-amd64-68
2021-12-21T18:43:00-9502339/openbsd-386-70-n1
2021-11-22T20:34:40-f13fcd9/openbsd-amd64-70
The text was updated successfully, but these errors were encountered: