Skip to content
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 ASCII download fails due to erroneous SIZE response #6564

Closed
awesomenode opened this issue Feb 4, 2021 · 4 comments
Closed

FTP ASCII download fails due to erroneous SIZE response #6564

awesomenode opened this issue Feb 4, 2021 · 4 comments
Assignees
Labels

Comments

@awesomenode
Copy link

Hi!

Found some FTP servers which refuse to give SIZE response in ASCII mode.
One such is proftpd, their reasoning is here: http://www.proftpd.org/docs/howto/ASCII.html

Now with the change in 7ea2e1d
it is not possible to download in ascii mode from these servers as the download fails on the 550 response to the SIZE command.

Prior to that the download continues with "unkown" size.

Could you please fix this, or eg add an option so we allow ASCII mode SIZE to fail?

I did this

FTP ASCII mode download from proftpd fails.

I expected the following

Download succeeds.

curl/libcurl version

7.74

operating system

Linux.

Thanks!

@bagder bagder added the FTP label Feb 4, 2021
@bagder
Copy link
Member

bagder commented Feb 4, 2021

Does the server really return a 550 in that situation? To me that seems... wrong.

@awesomenode
Copy link
Author

awesomenode commented Feb 4, 2021

$ curl -V
curl 7.71.0 (x86_64-pc-linux-gnu) libcurl/7.71.0 OpenSSL/1.0.2u zlib/1.2.7 libssh2/1.8.0
Release-Date: 2020-06-24
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL TLS-SRP UnixSockets
$ curl -B ftp://ip/welcome.msg -o /dev/null -v
*   Trying ip:21...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to ip (ip) port 21 (#0)
  0     0    0     0    0     0      0      0 --:--:--  0:00:09 --:--:--     0< 220 ProFTPD 1.3.5b Server (Debian) [ip]
> USER anonymous
  0     0    0     0    0     0      0      0 --:--:--  0:00:10 --:--:--     0< 331 Anonymous login ok, send your complete email address as your password
> PASS ftp@example.com
< 230-Welcome, archive user anonymous@ip !
< 230-
< 230-The local time is: Fri Feb 04 12:28:16 2011
< 230-
< 230-This is an experimental FTP server.  If you have any unusual problems,
< 230-please report them via e-mail to <root@>.
< 230-
< 230 Anonymous access granted, restrictions apply
> PWD
< 257 "/" is the current directory
* Entry path is '/'
* Request has same path as previous transfer
> EPSV
* Connect data stream passively
* ftp_perform ends with SECONDARY: 0
< 229 Entering Extended Passive Mode (|||2128|)
*   Trying ip:2128...
* Connecting to ip (ip) port 2128
* Connected to ip (ip) port 21 (#0)
> TYPE A
< 200 Type set to A
> SIZE welcome.msg
< 550 SIZE not allowed in ASCII mode
> RETR welcome.msg
< 150 Opening ASCII mode data connection for welcome.msg (170 bytes)
* Maxdownload = -1
* Getting file with size: -1
{ [177 bytes data]
* Remembering we are in dir ""
< 226 Transfer complete
100   177    0   177    0     0     16      0 --:--:--  0:00:10 --:--:--    40
* Connection #0 to host ip left intact

Yep it seems buggy to me also. But these are already out there. :(

@bagder bagder self-assigned this Feb 4, 2021
bagder added a commit that referenced this issue Feb 4, 2021
... as we ignore it anyway because servers don't report the correct size
and proftpd even blatantly returns a 550.

Updates a set of tests accordingly.

Reported-by: awesomenode on github
Fixes #6564
@bagder bagder linked a pull request Feb 4, 2021 that will close this issue
@bagder
Copy link
Member

bagder commented Feb 4, 2021

I went with skipping SIZE completely for TYPE A transfers. curl can't use the returned size anyway since servers tend to not send back the actual (converted) size for it so avoiding it seems like the better choice!

@awesomenode
Copy link
Author

Excellent, thank you Daniel!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

2 participants