On Mon, 14 Sep 2020, James Brown via curl-library wrote:
Thanks for digging deep into this issue!
I went through commits on master that aren't in 7.72.0 and came across
728f8d3bd
<https://github.com/curl/curl/commit/728f8d3bdc336e3fa838f45cad6c0133a6b604ae>,
which looks promising. It says it partially reverts a change from 7.65.2,
which is kind of weird because this problem does *not *occur for me in
7.71.1, which suggests that one of the other changes in 7.72.0 (maybe the
schannel stuff?) somehow had some spooky-action-at-a-distance and made this
much worse in 7.72.0.
Well, the problem this commit fixes is the opposite: libcurl would previously
reuse connections that actually are already dead and thus detecting the
"deadness" gets delayed.
I feel like 728f8d3bd still has a race condition if the FIN has been issued
by the server but not yet processed by poll, but that's neither here nor
there.
It's a race, sure, but that shouldn't be a problem. If the connection is dead
at the time extract_if_dead() is called, it should detect that and not reuse
the connection.
If it dies a millisecond after the check, the connection will instead be
reused and the sending of the outgoing request will subsequently fail. libcurl
will then attempt to create a new connection and retry the request over that.
If indeed calling extract_if_dead() there causes the problem for you, then I'd
like to get more information about what exactly the problem is within that
function so that we can address that rather than just reverting the commit
again and just go full yoyo on these issues!
--
/ daniel.haxx.se | Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://www.wolfssl.com/contact/
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
