Support for resuming aborted downloads

[ghost]

Are there plans to introduce support for resuming a previously aborted download? In my case, the size of the update packages is pretty big and it happens quite frequently that the user quits the app before the background updater reaches the ready-to-install-on-quit state. When the app is launched next time, Sparkle starts the download again from scratch.

I know of the delta updates feature, that can alleviate this problem to some extent but not solve it entirely. So can we add resuming downloads to the backlog, please?

[jakepetroules]

Yes, this would make sense. Would go along well with background downloads (like Chrome's updater), which is something I want to implement at some point.

[zorgiepoo]

I don't imagine this is hard to implement onto our existing use of NSURLDownoad, not if one doesn't mind about incomplete files lingering around for a little longer. I'm not sure if there are any security implications or if http + server support has to handle all that though (e.g. if the file on the client or server changes).

[kornelski]

We can safely do that for downloads signed with DSA.

I remember download managers used to resume files few KB earlier than necessary to compare the re-downloaded fragment with the existing data. That should be quite reliable in compressed formats.

[ghost]

That's great news, thank you! I wish I could contribute but currently I'm pretty overwhelmed...