Free Downolad Manager

Nov 25, 2010 at 10:11 AM

I use change set 3358 with IIS 7.5
    public ActionResult DownLoad(ResumableDownloadRequest ResumableRequest, string id)
      if (string.IsNullOrEmpty(id) || Path.IsPathRooted(id))
        return new HttpStatusCodeResult(400);

      var fileInfo = new FileInfo(Path.Combine(DownloadPath, id));

      if (fileInfo.Exists)
        ResumableRequest.FileName = id;
        return new ResumableFileResult(ResumableRequest, fileInfo);

      return new HttpStatusCodeResult(404);

So, Free Downolad Manager said, that server ranges not supported. May be where are any marks in HTTP headers of server milti-streaming support.

Nov 25, 2010 at 4:59 PM

Thanks for the report. I downloaded "Free Download Manager" and traced its request streams.

It's odd. When it first starts downloading it determines resuming is supported. Then it tries to do a new segment and decides resuming is actually not supported. I watched the requests and attached a debugger to see the results and it appeared that everything was returning as it should with the correct response code. The requested range is returned but FDM isn't happy. FDM is GPL so I'm going to see if I can review the code and see how it makes its determination on whether a server supports resuming. If I can see what it expects I might be able to convince it that resuming is supported.

Give me some time and see if I can resolve this.

Nov 27, 2010 at 8:39 PM

I didn't really get anywhere auditing the source code for Free Download Manager. There's quite a lot of it and I got tired of digging through files. Looking at the options I noticed FDM has a mode for advanced logging which shows the request and response messages. With this I found the error and I'm working on a fix for it. The problem is FDM issues an open-ended request for a range

Range: bytes=500000-

In this case, the ActionFilter assigns long.MaxValue to the end. During the binary write in the Result this is corrected but this is after the response header for the range was written.

Content-Range: bytes 500000-<long.MaxValue>/<actual file size less than long.MaxValue>

FDM saw this as an error and decided it was not safe to try to resume the download. Correcting the output to reflect the proper end-byte value was all it took and FDM was satisfied and determined the download was capable of being resumed. I retried the download process, stopping it midway and resuming and everything seems to work just as expected. I'm going to do a bit of code cleanup and get the byte ranges corrected earlier in the result processing so I don't have duplicate checks and I'll commit the code later today.

Nov 27, 2010 at 9:50 PM
Edited Nov 28, 2010 at 2:44 AM

Updated source has been committed which resolved the problem in my local testing. Please try it out and let me know if the problem persists.

Thanks for reporting this!