FTP, EPSV and SIZE
Date: Tue, 27 Nov 2001 16:25:16 +0100 (MET)
A few FTP issues I need some thoughts on:
I've more or less made curl support the FTP command EPSV (it was so easy I'm
embarassed I haven't done this before), which makes passive fetches on IPv6
work (even if the command can be used on many IPv4 servers too). EPSV is
documented in RFC2428.
Can anyone see any major drawback in making curl attempt to use EPSV before
PASV when doing passive retrieves? If unsuccessful, it adds another
command-response time before the transfer can begin. I don't know exactly how
widespread the support of the command is (on the server side). One approach
could be to only attempt EPSV if compiled IPv6-enabled, as the command isn't
strictly required for IPv4 hosts.
While doing this closer inspection of curl's FTP command session, there's
another issue that we see at times: when we download an FTP URL but the
server doesn't send the size in the RETR response. We then download the file
without knowing the full size. This does not only make a badlooking progress
meter, but for all programs that use libcurl to download files it can also be
a nuisanse and the only way a program can circumvent this is by first
issueing a request for the size and then fetch it. Knowing the size on the
file before-hand is also the only way to know if a transfer is aborted.
I suggest that we add a SIZE command to the command sequence as well. We
attempt to figure out the size before it is retrieved. SIZE is not documented
in any RFC, but is very widely used. Many servers that don't send the file
size in the RETR response still supports the SIZE command.
This will always delay the download start with a command-response round-trip
time, but I think it could be worth it. Any objections?
-- Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/Received on 2001-11-27