Feature Requests item #3488178, was opened at 2012-02-16 03:21
Message generated for change (Comment added) made by shaberman
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350976&aid=3488178&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: command line client
Group: download
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andrew Zhezherun (zhezherun)
Assigned to: Daniel Stenberg (bagder)
Summary: [patch] Retry on CURLE_COULDNT_CONNECT

Initial Comment:
When using curl, I sometimes get random "couldn't connect to host errors". I am not sure what is causing them, but the server looks to be operational, and running the same command after a few seconds usually works. I tried to use the --retry option, however it turned out that it treats CURLE_COULDNT_CONNECT as a fatal error and does not try again if it occurs. Could this error code be included please when curl determines whether to retry? I have attached a patch that should address this issue.

----------------------------------------------------------------------

Comment By: Stephen Haberman (shaberman)
Date: 2012-02-27 10:09

Message:
FWIW, I consider a TCP connect error "transitional" (or at least temporary)
if we're waiting for the server to come up. I've seen multiple application
startup scripts try and use "curl --retry" to wait for the http server to
start, but instead have to be switched to use "wget --retry-connrefused"
instead.

Perhaps you could use another flag like wget does, as though you assert
that just doing a loop for "tcp connect" in the shell script calling curl
is an option, by the time you add sleeping/limited retries/etc., it really
is preferable for me as a user to just let curl use its existing
sleep/retry functionality instead of me reimplementing it for the 1 error
(tcp connect) that it doesn't loop on.

----------------------------------------------------------------------

Comment By: Andrew Zhezherun (zhezherun)
Date: 2012-02-16 04:01

Message:
Thanks for the comment! I am not sure what the definition of a transitional
error exactly is, but in my case the error does change over time as it
disappers after retrying. If curl's treatment of error codes is strict,
then maybe there could be a separate option e.g. --retry-on-all-errors that
would achieve what I want. I agree that I can write a wrapper script
instead, I just thought that it would be nicer to have this option directly
in curl, in case I am not the only one having this problem.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2012-02-16 03:37

Message:
The point with --retry is to make it retry operations for transitional
errors. Those are errors that are likely to change over time. Most of the
transitional ones are such due to what the application layer protocol
itself says they are.

I don't think a failure to do a TCP connect is a typical transitional
error. I also don't think that adding non-transitional errors to the list
of errors to do retry for is a good idea, as if we can add such we pretty
much can ditch the check and retry for all possible errors.

For your particular problem here and now, you can quite easily write a
shell script for your case that re-sends the same command if this
particular error is returned.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350976&aid=3488178&group_id=976
Received on 2012-02-27