3 ms·
Pedantic correction: > Does it have resume capabilities? Nope. See RFC 959, > RESTART (REST) > > The argument field represents the serv
by eganist 9y ago
Pedantic correction:
> Does it have resume capabilities? Nope.
See RFC 959,
> RESTART (REST)
>
> The argument field represents the server marker at which
> file transfer is to be restarted. This command does not
> cause file transfer but skips over the file to the specified
> data checkpoint. This command shall be immediately followed
> by the appropriate FTP service command which shall cause
> file transfer to resume.
And it would seem the definition from the RFC isn't even what's commonly implemented anymore, per https://cr.yp.to/ftp/retr.html https://cr.yp.to/ftp/retr.html (ctrl/cmd+f "The REST verb" no quotes)
Finally, if we're including HTTPS and comparing HTTP v FTP, why not include FTPS? https://en.wikipedia.org/wiki/FTPS https://en.wikipedia.org/wiki/FTPS (edit: probably because Chrome doesn't support it. Heh.)
- mmahemoff 9y agoI remember the collective joy when ncftp [1] turned up as an alternative to the default ftp client, suddenly making it possible to resume FTP transfers. An important feature when you've initiated a large (several MB) file with a dialup modem but someone in the house needs to make a phone call. IIRC FTP clients throughout the '90s were actually more reliable than browsers at resuming downloads. 1. https://en.wikipedia.org/wiki/NcFTP https://en.wikipedia.org/wiki/NcFTP
- fiddlerwoaroof 9y agoI've never had a good experience with browser resume: I generally copy the link and then use aria2/curl/wget to actually get the file
- ryan-c 9y agoIIRC in the late 90's to early 2000's "download managers" that could reliably resume were fairly popular.