-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
Curl does not retry on 504 #8845
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
Labels
Comments
On Fri, May 13, 2022 at 09:00:31AM -0700, jakub-bochenski wrote:
I did this
curl --fail-with-body --show-error -vvv --oauth2-bearer SNIP --retry 5 -X PUT -H 'Content-Type: application/json' -d @- https://graph.microsoft.com/beta/trustFramework/keySets/B2C_1A_PrimaryUserstoreSecret
...
curl: (22) The requested URL returned error: 504
I expected the following
Retry 5 times, then fail with code 22 if it still not suceeded
This seems to be related to the use of --fail-with-body. Dropping that option
makes curl retry as expected. --fail-with-body is documented to "Return an
error on server errors where the HTTP response code is 400 or greater" so it
could be argued this is correct behaviour. Except, the documentation compares
this option to --fail which *does* do the retries before returning an error, so
I suspect this is actually unintentional curl behaviour.
Dan
|
Well uh, how else can I get URL to return a 22 code on error, print the body and still do retries? |
Well, you could continue arguing here that it's a bug that somebody needs fix.
Or, you could push the proposal that JSON output should include the body. Or,
you could drop the --fail-with-body option and parse the output yourself to
extract the last body. Or, there are probably other ways neither of us have
thought of yet.
|
What do you mean? What is "JSON output" in context of curl? |
https://daniel.haxx.se/blog/2020/03/17/curl-write-out-json/
Somebody subsequently proposed that the request body be included as a JSON key,
but this was rejected (with good reason, I should add). I'm just suggesting
that this proposal, if the objections could be overcome, might be another way
to solve your problem if it's decided that --fail-with-body is doing the right
thing now and won't be changed, which I personally think is not the case.
|
Thanks. FTR I'm after response not request |
%{json} gives you a bit of both.
|
It might be as easy as this: diff --git a/src/tool_operate.c b/src/tool_operate.c
index daaf0bcd4..67de59c0a 100644
--- a/src/tool_operate.c
+++ b/src/tool_operate.c
@@ -433,11 +433,11 @@ static CURLcode post_per_transfer(struct GlobalConfig *global,
curl_easy_getinfo(curl, CURLINFO_OS_ERRNO, &oserrno);
if(ECONNREFUSED == oserrno)
retry = RETRY_CONNREFUSED;
}
else if((CURLE_OK == result) ||
- (config->failonerror &&
+ ((config->failonerror || config->failwithbody) &&
(CURLE_HTTP_RETURNED_ERROR == result))) {
/* If it returned OK. _or_ failonerror was enabled and it
returned due to such an error, check for HTTP transient
errors to retry on. */
long protocol = 0; |
bagder
added a commit
that referenced
this issue
May 13, 2022
... in the same way --fail already does. Reported-by: Jakub Bochenski Fixes #8845
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I did this
I expected the following
Retry 5 times, then fail with code 22 if it still not suceeded
curl/libcurl version
curl/7.81.0
operating system
The text was updated successfully, but these errors were encountered: