-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
Regression from 8.11.0 when performing ftp custom request #16380
Comments
Does it work correctly if you do not reset the handle in between the transfers? |
It would make analysis of what is going on easer if you create a curl trace (via
after the global init. If there is an SSL error it points to curl trying to open a new connection for the reset easy handle instead of reusing the previous one (I am guess here that is what you want). The trace would show exactly what is happening. |
Is there a nightly build i can download somewhere to try out? |
Not for the pull request. Once merged, I believe someone does builds. @vszakats can you help? |
Yes, you can find daily builds here: https://github.com/curl/curl-for-win/actions/workflows/daily.yml |
Perfect. I will follow the pr, and when merged, try the nightly build and see if it solves the issue. |
I know that #16392 is not merged yet. Just wanted to let you know that the most recent daily build still has the issue. Here is a dump with `curl_global_trace('all')` as requested
|
I did this
The following has worked fine up to and including v. 8.11.0. I am trying to upgrade to 8.12.1 and I start to see this issue.
To support different ftp servers I have the following logic in my code:
FTP_COULDNT_RETR_FILE
, then try and send a LIST command - read and parse the responseMy problem exist when the server does not support the MLSD command, and I then re-use the curl easy handle for the next LIST command. There is a call to
curl_easy_reset
in between the two perform operations. This has worked fine until now, but I now get aSSL_CACERT
error code when running the second LIST perform operation. It seems as if the handle is not correctly reset with respect to tls when reset is invoked on a handle that has returned an error.If I use two different curl easy handles, one for each of the commands, then it works just fine.
Verbose output from the debug function for a session to a vsftpd server that does not support MLSD
I expected the following
I expect that I can re-use the easy handle after a
curl_easy_reset
even though the perform operation on that handle did not succeed.curl/libcurl version
libcurl 8.12.1
This previously worked in 8.11.0
operating system
Windows, with 64 bit build from https://curl.se/windows/
The text was updated successfully, but these errors were encountered: