net: on Windows, a Write on a connection closed by the remote peer causes Read to return WSAECONNABORTED
#60315
Labels
Comments
|
(CC @golang/windows) |
|
I think this is related to the scenario described in https://www.chilkatsoft.com/p/p_299.asp. |
|
Yes, this appears to be that exact scenario: If a connection has data in its read buffer and has been closed by the peer, writing to the connection will cause the readable data to be discarded and future reads to return an error. Not the behavior I'd choose, but this appears to be WAI on Windows. |
bcmills
changed the title
WSAECONNABORTED
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Filing this as an offshoot of discussion on https://go.dev/cl/496056.
That CL fixes a flaky test by delaying the
Closeof anet.Connuntil after the recipient has read data written to it. This shouldn't be necessary; if we write some bytes to a conn and then close it, the other end should read the bytes before getting a connection close error.Turning on debugging of HTTP/2 frame reads and writes for that test (without CL 496056) seems to show the server side writing a GOAWAY frame and then closing the conn, followed by the client side reading a
"wsarecv: An existing connection was forcibly closed by the remote host"error without ever seeing the GOAWAY frame.It's possible I've missed something and this is actually an HTTP/2 bug that I can't yet see; I haven't tried reproducing the behavior in isolation yet. But right now it looks to me like writing to a
net.Connand then immediately closing it can lose the write on Windows.The text was updated successfully, but these errors were encountered: