-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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
Proxy-level timeout as FIN is not handled as error #5992
Comments
strace, the relevant bit:
|
In this case, you haven't gotten anything back from the remote server? Ie the request is sent off but nothing has seen in the form of a response status line or headers? |
Correct, the socket is closed before any data is received. The request bytes were written, and thirty seconds later (the timeout) the connection is closed with a FIN |
I can reproduce it and I might have a fix pending... |
... 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
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
0
.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:
curl/libcurl version
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.
The text was updated successfully, but these errors were encountered: