Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Proxy-level timeout as FIN is not handled as error #5992
Some proxy in my environment appears to have a 30 second timeout, and will send a FIN back when this happens. When curl sees this, it does not recognize that this is an error (it is indeed not a RST), and it proceeds normally. In libcurl, CURLINFO_RESPONSE_CODE is reported as
To reproduce, find a proxy that has this behavior (I'm told it's Squid, not sure how to configure it this way, but any CONNECT-based proxy that sends a FIN while in the middle of processing a request should do), then run this test command (thanks to a stranger on the internet for hosting this):
It produces output along the lines of:
I expected the following
The server did not send a response, and thus an error condition should be marked.
By comparison, wget does consider this an error condition and will retry:
Fresh build (autoreconf -fi, ./configure, make -j4) from the master branch. But, also reproducible on the CentOS 7 curl 7.29.0 build with its bazillion backports.
strace, the relevant bit:
... as that counter is subsequently used to detect if nothing was returned from the peer. This made curl return CURLE_OK when it should have returned CURLE_GOT_NOTHING. Fixes #5992 Reported-by: Tom van der Woerdt