hasty
24th February 2002 00:21 UTC

NSISDL with HTTP Resume
Don't know if anyone's interested in this, but here's a patch for NSISDL. The three main changes are:

1) Now supports HTTP Resume. If a file download was partially completed the last time a download was attempted, and the filesize on the server hasn't changed, NSISDL will pick up where it left off. This is useful for large files.
2) It now estimates the time remaining in the download, and prints it out after the progress percentage. (also, file sizes are reported in K)
3) Fixed a bug where NSISDL reported success if disconnected in the middle of downloading.

Can't say it's well written, but it works.

-H

Tresni
24th February 2002 07:54 UTC

--------------------Configuration: nsisdl - Win32 Release--------------------
Compiling...
nsisdl.cpp
Linking...
   Creating library Release/nsisdl.lib and object Release/nsisdl.exp
nsisdl.obj : error LNK2001: unresolved external symbol _time
../../nsisdl.dll : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.

nsisdl.dll - 2 error(s), 0 warning(s)

yaroslav
24th February 2002 08:26 UTC

_time is from libc. attached is nsisdl with
Hasty's d/l resume patch that doesn't use libc :)

justin
4th March 2002 03:52 UTC

I'm not sure I'm on board with some of the issues http/1.1 support adds.. primarily, the issues are:

• support on non http 1.1 servers
• preventing corruption on downlaoded files (i.e. suppose the user is upgrading from one version to another, and accidentally resuming from an old version to a new one). - this one isn't too big of a deal, but just requires the person writing the script to write it intelligently.
• uh, creating registry keys that never get deleted sucks.

hasty
4th March 2002 17:26 UTC

So, the way it handles the resume of a possibly changed file is by comparing filesizes. This is the info it stores in the registry. For me, this was enough, since the files I'm downloading are 4MB+, and thus any changes to the build large enough to make it to production are most likely going to change the filesize. However, I can see that if you were using NSISDL to fetch, say, an ini file, it may very well be the same size and a different version. So, adding something based around the "Last-Modified" header would solve that problem. At the time, writing something to parse HTTP-date fields was more than I felt I could pull off in a couple hours.

In any case, as it stands, if the size reported by the server differs from that in the registry, it starts the download over again. This should also take care of any non-HTTP1.1 servers, since it will report the full size of the download, which, added to the size already downloaded, would be incorrect, triggering a re-download. Which is all you can really expect from a server that doesn't support resume. That's not really perfect, either, since it is possible that the server filesize would have changed to exactly the right size to match up with the old filesize minus the current amount downloaded, but that would be fixed by the above timestamping.

As far as the registry goes, it can certainly be improved by deleting the reg value after a successful download, and removing the NSISDL key if there are no more subvalues. It would still be possible that a key would left behind if a user never finished his or her download, and I can't really think of a way around that. The "metadata" about the partially downloaded file needs to live somewhere.

-H