Download Resumption in Internet Explorer
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).
One of the significant enhancements in the IE9 Download Manager is enhanced support 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:
- The URL must be HTTP or HTTPS
- The server must not have sent the response header Accept-Ranges: none
- The server must send a strong ETAG header on the response
- 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-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
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.
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. 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.
 IE8 and below could resume downloads under ideal circumstances, but in practice these circumstances were very rarely achieved.
 For instance, Download.com isn’t currently sending ETAGs on their file downloads.
 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.