The initial motivation is to make WinHttpCloseHandle(request) with request previously upgraded to websocket deliver WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING right away and not after websocket is closed much later (this late notification causes crash in Microsoft Flight Simulator). That happens so as the notification is sent when the object is destroyed, not when the handle is closed. This logic seems correct to me: when testing some more things involving closing handles and observing which threads get the notifications I saw Windows delivering WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING in the other threads, which suggests that the notification can be queued and delayed on Windows too in case there are pending operations involving the object.
So the right thing to do seems to be to have just the separate websocket and do not reference request from it.
It probably deserves a separate explanation why I am adding a refcounting to netconn and copying it to webscoket instead of just nullifying the netconn in request. Doing that way (just nullifying the netconn in request) immediately caused regression in Elden Ring which started failing in a convoluted way: it doesn't wait for WebSocketReceiveResponse() to complete and calls WebSocketCompleteUpgrade(). That currently succeeds in Wine due to some lack of validation. Then, after upgrade, async WebSocketReceiveResponse proceeds, but with NULL netconn it gets an error from prior WebSocketReceiveResponse in callback and fails the thing. The core problem here is that unless recursive request is involved WebSocketReceiveResponse is always sync on Windows and, as my testing goes, does not involve network communication at all. I. e., looks like the actual reply receiving should be done in WebSocketSendRequest, WebSocketReceiveResponse only sends notifications and possibly queues recursive reque sts. I have a WIP patches for that and_with the help of those and existing winhttp test I realized that removing connection from request is wrong even without convoluted story. We have an existing test in winhttp.c which performs second request / upgrade on a request already upgraded socket. The test as is succeeds even with NULL connection in request by that is by chance only (as we don't try to receive response from our in process server yet which is failing in this case). With connection removed request opens a new one which doesn't get processed by our server, while in the same test on Windows I see that request is actually received by server, suggesting that it uses all the same existing connection on Windows, and so we should keep the same connection in request.
As a separate note, I suspect that we now can erroneously cache connection for request upgraded to websocket. But that happens not on request close but under different conditions and looks the same before and after present patches, so this should be probably checked and fixed separately.
Patch "winhttp: Move read buffer to websocket." might look weird as introducing the buffer for the only purpose of preserve initial data. While I don't immediately see how that can be done simplier, I have another small excuse for that. Currently the logic of closing websocket handles does the correct thing WRT notifications and aborting the operation. Yet it is still racy a bit due to we use app's buffer in socket read calls. If we happen to receive some data already after we sent notifications but before the read operation is aborted it may write to already freed or otherwise reused app's buffer. It seems to me that the only clean way to deal with that later is to use our own read buffer and copy the data only when we are going to send non-abort completion notification. So this read buffer might have more use in the future.