IEInternals

A look at Internet Explorer from the inside out. @EricLaw left Microsoft in 2012, but was named an IE MVP in '13 & an IE userAgent (http://useragents.ie) in '14

Download Resumption in Internet Explorer

Download Resumption in Internet Explorer

  • Comments 18

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.

  • Huh? No resumption for FTP?

  • @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.

  • Interesting. But apparently someone is working on a standard for this: tools.ietf.org/.../draft-ietf-ftpext2-hash & tools.ietf.org/.../draft-bryan-ftp-range

  • 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.

  • @mcm_ham: Please provide either a URL or a Fiddler capture of your download.

  • @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.

  • @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.

  • @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.

  • 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...

  • 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!

  • Thank you for your quick response. Would greatly appreciated your help if we can get this to work. We are working on a high profile project and the pause resume feature very essential.

  • How can we configure an out of the box iis7 setup to permit download resumption for clients that support it?

  • My case is really weird. I wrote a HTTP server. It supports download resumption with Firefox and Chrome but IE9. The pause and resume button are clickable. But IE9 does not even send "Range: bytes=xxx" and "If-Range: xxx" in the HTTP GET header for resuming. I have duplicated the same HTTP header and ACK as www.kernel.org (IE9 download resumption works with this site), the IE9 still does not want to include "Range :bytes=xxx" in GET header for resuming. I think IE9 may also check something in TCP layer for download resumption.

  • <<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.

  • Why would you require an ETag, my experience is that ETags are invariably broken in many instances due to how they're being generated by default on most servers. The default in most cases is a hash of modified time, size, and inode, which is all well and good until you start running a load balanced farm of servers where you can not guarantee consistent inodes for individual files. I honestly do not understand why you simply wouldn't use the Last-Modified header to validate, ETag certainly isn't required for byte-range support so you're just adding in a bit of nonsense for no reason other than to overly complicate things.

Page 1 of 2 (18 items) 12
Leave a Comment
  • Please add 6 and 7 and type the answer here:
  • Post