Don't retry requests with CURLOPT_NOBODY except for HTTP retries #1243
Conversation
@Marwes, thanks for your PR! By analyzing the history of the files in this pull request, we identified @bagder, @dfandrich and @yangtse to be potential reviewers. |
I think we probably should make that rule (no_body && !using-HTTP) so that it gets retried for the HTTP case, but not for other protocols. |
a28ef97
to
5fa8cb8
Ok, I think I got that and the explanation correct now but feel free to change it. |
5fa8cb8
to
71a32a5
Using sftp to delete a file with CURLOPT_NOBODY set with a reused connection would fail as curl expected to get some data. Thus it would retry the command again which fails as the file has already been deleted.
71a32a5
to
59ad111
thanks! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
This reverts commit 31e33a9.
Using sftp to delete a file with CURLOPT_NOBODY set with a reused connection would fail as curl expected to get some data. Thus it would retry the command again which fails as the file has already been deleted.
This issue had originally been fixed in 12f5c67 which I found out about from https://curl.haxx.se/mail/lib-2006-02/0029.html. However the fix got removed in 31e33a9. A straight revert as this PR does currently is perhaps not sufficient as there should at least be a comment explaining the reason for the
!data->set.opt_no_body
check (should it perhaps only be for FTP to not interfere with HTTP as mentioned in 31e33a9?) so I'd be happy to amend this PR with a better fix.