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
curl_easy_reset() does not reset text/binary option for FTP transfer #6577
Comments
I renamed it to be more specific |
I don't think your example case shows any bug. Your code inserts a If you instead do |
Well, the "TYPE A" command is also issued via curl's CURLOPT_PREQUOTE option), so it's actually not behind curl's back. At least it should be documented that commands executed by the CURLOPT_PREQUOTE and CURLOPT_POSTQUOTE options are executed unnoticed by curl and not unset by the curl_easy_reset() function, which can cause problems afterwards, thus the developer is responsible for unsetting anything changed by these commands.
This is obviously not the case. Of course setting CURLOPT_TRANSFERTEXT=1 during upload the step would be the obvious cure, |
Yes, but libcurl does not parse your commands, so you're effectively changing state of the connection without informing libcurl about it.
Yep, and it's a known and documented limitation "that nobody has rectified" to quote the docs.
Is it really so or is the "TYPE A" simply a sticky command that is in effect until you actually issue "TYPE I"? |
I still claim it is the case even if it is a bit of a word game. The handle knows what state it wants and the reset restores that "wanted state" to default. What happens isn't related to the handle's state, what happened was that the connection has been modified to be in a different state than libcurl knows about. |
... so passed in commands may confuse libcurl's knowledge of state. Reported-by: Bodo Bergmann Fixes #6577
So, why is libcurl still producing carriage returns in the output on Unix when I explicitly tell it, that this is an ASCII transfer (so it should remove any incoming carriage returns)? And I still claim, that it is at least a documentation issue - if not for curl_easy_reset(), then for the CURLOPT_PREQUOTE and CURLOPT_POSTQUOTE options. |
That's unrelated to this bug report though and is about curl not doing the necessary text-translations for FTP ASCII transfers. It is mentioned in the CURLOPT_TRANSFERTEXT option man page. This is a known flaw. |
I do not actually expect a code change, I am fine with a clarifying documentation change for the CURLOPT_PREQUOTE and CURLOPT_POSTQUOTE options (not sure if other options are also affected) to help others to avoid problems like this, i.e. as the libcurl documentation is refered to by others (e.g. wrapper libraries for other languages). BTW, thanks for the very quick response. |
#6580 attempts to clarify the curl-not-parsing-quote-commands situation |
Transfer after curl_easy_reset() uses incorrect options, thus still happening in ASCII mode, even when explicitly setting CURLOPT_TRANSFERTEXT to 0.
In addition, this also causes '\r' (carriage returns) to be written to the output on Unix, which is wrong for both ASCII and binary mode.
To reproduce
Example C code
Example usage
From bash (ftpdld is the name of the executable created from code above):
printf "Line1\nLine2" | ftpdld | od -cx
Workaround
Instead of curl_easy_reset() use a new curl handle for the download.
Expected output
Verbose output (stderr) should indicate binary mode (TYPE I) being used for download.
File downloaded only contains newline (no carriage return) as end-of-line characters.
Actual output
Verbose output (stderr) indicates that ASCII mode is used for download.
File downloaded contains carriage return + newline as end-of-line characters.
curl/libcurl version
libcurl/7.74.0
operating system
Linux xxxxx 3.10.0-1062.el7.x86_64 #1 SMP Thu Jul 18 20:25:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
The text was updated successfully, but these errors were encountered: