mirror of
https://github.com/sigoden/dufs.git
synced 2026-04-08 16:49:02 +03:00
[GH-ISSUE #267] Possible to resume downloads after Network Disconnect? #140
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @blackops786187 on GitHub (Sep 21, 2023).
Original GitHub issue: https://github.com/sigoden/dufs/issues/267
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:
@sigoden commented on GitHub (Sep 23, 2023):
DUFS already supports resumable downloads, you can test it with:
@blackops786187 commented on GitHub (Sep 23, 2023):
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
@sigoden commented on GitHub (Sep 24, 2023):
Everything is working fine in Chrome as well
@blackops786187 commented on GitHub (Oct 26, 2023):
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.
Of course this issue doesn't manifest when i dont use any auth mechanism. I can record a video if it helps
@sigoden commented on GitHub (Oct 26, 2023):
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