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
Possible to resume downloads after Network Disconnect? #267
Comments
DUFS already supports resumable downloads, you can test it with:
|
Yes. I’m aware of that. Just wondering why chrome isnt able to resume it despite dufs supporting it. I can’t really ask a user to use curl to resume a download |
Hi, I belive i've located the issue behind my downloading failing to resume. It seems like using https whilst using untrusted certs prevents the resume of the download since it doesn't implicity trust the connection. I have rectified this although i am now seeing a different issue If i use the basic auth switch, start the download and then cut the network off for a period of time, then reconnect it and attempt to resume the download, the chrome download manager flags the downloadd as failed and requiring authorisation despite not closing the browser. This subsequently deletes the partial crdownload file preventing the resumation of it, I would have assumed that basic auth stays cached whilst the browser is open so not sure whats going on here. |
Resume download works on Basic Auth, fails on Digest Auth. dufs can't do anything about it. Note: The default auth method of Dufs is digest |
Problem
Thanks for creating this simple tool. It has made sharing large files between people very simple.
As the title suggests, is it possible to resume a download after the server network has disconnected and the HTTPS connection has terminated. On chrome, when the disconnect happens, the browser marks the download as failed and clicking on resume doesn't seem to restart it from where it left off. Is this the normal behaviour for HTTP ? With SFTP, it has the capability to resume even after a complete termination of connection although i would like to use HTTP as the protocol since the speed doesnt suffer when the RTT is high and the file transfer is happening over the WAN
Environment:
The text was updated successfully, but these errors were encountered: