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
FTP: using TLS on data channel blocks connection reuse #4329
Comments
For the FTP case it should only be a concern if the "close notify" message is received on the primary control connection, not on the data connection - which I suspect is what happens for you. Can you verify that when this happens wrongly for you, is the |
Yes num = 1, i.e. the data channell is receiving 0 bytes from SSL_read(). |
I hope #4340 fixes the problem for you? |
Yes, it does: I'm seeing only a single "AUTH SSL" in my test case (and runtime went down from 14 to 6 sec). Thank you! |
Hi,
when setting CURLOPT_USE_SSL to CURLUSESSL_ALL, recent libcurl builds have become extremely slow. After debugging it became clear why:
Even when reusing the same easy handle, the control connection is closed after every FTP data download, instead of being kept open.
Looking at Wireshark the logs are filled with lots of "AUTH SSL", when there should in fact be only a single one.
Reproduce:
curl --user demo:password --ssl-reqd ftp://test.rebex.net//pub/ ftp://test.rebex.net//pub/example/
Expected: only 1 "AUTH SSL"
Actual: 2 "AUTH SSL"
The problem is caused by the following commit:
3f5da4e#diff-7dafef8d70eee3940c9184e4e4e93448
The changes in the commit issue a
connclose(conn, "TLS close_notify");
when the FTP data channel is finished with the transfer, but this closes the whole FTP connection, including the control channel! Although the easy handle is reused, it has to authenticate again.
Solution: Maybe skip the changes of the above commit in the FTP case?
The text was updated successfully, but these errors were encountered: