Jaa

Download Resumption in Internet Explorer

  • Artikkeli

While most file downloads are quickly and successfully completed, some large downloads take a long time to complete, and may be interrupted in the middle by either the user choosing to “Pause” or due to networking glitches (e.g. WiFi connection dropped).

image

One of the significant enhancements in the IE9 Download Manager is enhanced support[1] for download resumption. Download resumption enables users to resume the transfer of a file at the point of interruption instead of re-downloading the entire file over again. In order for Internet Explorer to consider a download to be resumable, several conditions must be met:

  1. The URL must be HTTP or HTTPS
  2. The server must not have sent the response header Accept-Ranges: none
  3. The server must send a strong ETAG header on the response
  4. The server must respect the Range header on the subsequent download request

Download resumption works by sending a HTTP Request specifying what version of the resource the client currently has (identified by the ETAG) and the range of the file that the client would like the server to send. For instance, here’s the request that is sent if the user clicks the Resume button in the download manager:

GET /BigFile.exe HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: 127.0.0.1
Range: bytes=700000-
If-Range: "StrongETAG"
Connection: Keep-Alive

If the server is capable of resuming the download, and the version identified by the client (using the If-Range header) is still available, the server will send a HTTP/206 response with a Content-Range header indicating the portion of the file that the server is sending. If the server is unable or unwilling to deliver the range requested by the client, it may send a HTTP/200 response and start the download over from the beginning.

In some cases, we’ve heard from users who do not understand why they cannot resume certain incomplete downloads.

Some servers simply don’t allow download resumption, either forbidding it explicitly using Accept-Ranges: none or implicitly by never returning a HTTP/206 response. The advantage to explicitly sending Accept-Ranges: none is that the Download Manager’s Pause button is disabled, to spare the user from trying to pause a download only to find out later that they must restart it from the beginning.

image

In many cases, the problem is that the server failed to specify an ETAG that allows the client to ensure that it is resuming the correct file[2][3]. In a few cases, we’ve seen servers that send “weak” ETAGs; strong ETAGS must begin and end with quotation marks. If the response lacks a strong ETAG, the Pause button is disabled.

Even when a server otherwise supports resumption, in some cases, it will fail because the server requires some state information to allow the request (e.g. a Session cookie or HTTP Authentication) which is no longer available, because, for instance, the user closed and reopened the browser before attempting to resume.

-Eric

[1] IE8 and below could resume downloads under ideal circumstances, but in practice these circumstances were very rarely achieved.
[2] For instance, Download.com isn’t currently sending ETAGs on their file downloads.
[3] Sites that send Vary headers on their responses should also always send an ETAG on such responses to allow the browser to conditionally revalidate such responses.

Comments

  • Anonymous
    June 03, 2011
    Huh? No resumption for FTP?

  • Anonymous
    June 03, 2011
    @Bjorn: That's correct, WinINET does not support resumption of FTP transfers. While some FTP servers can resume, FTP has no real mechanism for resource version identification.

  • Anonymous
    June 04, 2011
    The comment has been removed

  • Anonymous
    June 24, 2011
    Thanks for the info about etag, I couldn't figure out why IE9 had it's Pause button disabled. Unfortunately I seem to be getting downloads restarting when I click Resume in my handler that I don't get in other browsers. stackoverflow.com/.../5429947.

  • Anonymous
    June 25, 2011
    @mcm_ham: Please provide either a URL or a Fiddler capture of your download.

  • Anonymous
    June 25, 2011
    @EricLaw thanks for the assistance. Here is the url and fiddler capture: www.minsoft.org/handler.ashx www.minsoft.org/HandlerCapture.xml How come if I download normally not thru the handler where resume works, do I not get 206 or Accept-Ranges in the Response capture? www.minsoft.org/SuccessfulResume.xml Edit: Oops, that was an IE9 development tools capture. If I run Fiddler then the entire file downloads first (I can see the download progress in Fiddler) before the browser offers to save the file, by which time I can't pause the download. Happens with any browser.

  • Anonymous
    June 27, 2011
    @mcm_ham: In Fiddler, you'll need to enable Streaming mode (see the toolbar button) if you want the browser to go through the normal download experience. A quick test suggests that your handler page resumes just fine: GET /handler.ashx HTTP/1.1
    Range: bytes=94208-
    If-Range: "0.9.12"
    Host: www.minsoft.org

    HTTP/1.1 206 Partial Content
    Content-Length: 1100158
    Content-Range: 94208-1194365/1194366
    Content-Type: application/x-msdownload
    ETag: "0.9.12"
    Accept-Ranges: bytes How are you determining that you're not getting a 206?  Don't trust what you see in the IE9 F12 Developer Tools here; WinINET, below the F12 Tools, seamlessly turns a HTTP/206 into a HTTP/200 and restitches the file as it goes. You should use Fiddler if you want to see the HTTP/206.

  • Anonymous
    June 27, 2011
    @EricLaw thanks, using fiddler I could compare the sites where it was working and see that I was missing the word "bytes" at the beginning of the value for the "Content-Range" header. Now my handler correctly resumes in IE9.

  • Anonymous
    September 12, 2011
    I am trying to download large files from azure blob storage using IE9. I cannot pause/resume these files. I generate a singed URL and redirect the users from my web app to download files from blob. Any idea why the pause resume does not work? [EricLaw]: Do you have a sample url I could look at? Azure had a bug where they didn't send a valid ETag (they omitted the quotes) but I thought that would be fixed by now...

  • Anonymous
    September 13, 2011
    Here is a sample URL to download from blob kofaxexternalams.blob.core.windows.net/.../WAPTKVS2010-August2011Refresh.exe [EricLaw]: Yes, that's the Azure ETAG bug. I'll ping the Azure guys. Thanks!

  • Anonymous
    September 13, 2011
    The comment has been removed

  • Anonymous
    October 05, 2011
    The comment has been removed

  • Anonymous
    January 21, 2012
    The comment has been removed

  • Anonymous
    January 21, 2012
    <<I think IE9 may also check something in TCP layer for download resumption.>> Nope. Please email me (use the Contact link at the top right) a copy of the headers for the original download request. Use Fiddler to capture them.

  • Anonymous
    May 25, 2012
    The comment has been removed

  • Anonymous
    May 26, 2012
    @Brett: You probably should read RFC2616 to get a better understanding of how HTTP works.

  • Anonymous
    April 24, 2013
    The comment has been removed

  • Anonymous
    December 05, 2013
    @EricLaw: I'm struggling with a issue, IE restarts the download instead of resuming download while I clicking on the Resume button for the first time, if the downloaded file name contains non ascii characters, such as Chinese characters, it works on firefox. What's more, It works perfect if the file name only contains ascii characters. I found the problemtic code is: AddHeader(response, "Content-Disposition", "attachment;filename="" + HttpUtility.UrlEncode(fileName) + """) But i really don't know why? Is it a know issue of IE download manager?