端断点续传，它就在初始的响应中发送Accept-Ranges头信息。服务器还发送一个实体标签（entity tag）头信息（ETag），它包含一个唯一的标识字符串。

　　下面的代码显示了IIS发送给客户端的用于响应一个初始下载请求的一些头信息，它向客户端传递了被请求的文件的详细信息。

HTTP/1.1 200 OK
Connection: close
Date: Tue, 19 Oct 2004 15:11:23 GMT
Accept-Ranges: bytes
Last-Modified: Sun, 26 Sep 2004 15:52:45 GMT
ETag: "47febb2cfd76c41:2062"
Cache-Control: private
Content-Type: application/x-zip-compressed
Content-Length: 2844011

　　在接收这些头信息之后，如果下载被中断了，IE浏览器在后来的下载请求中会把Etag值和Range头信息发送回服务器。下面的代码显示了尝试恢复被中断下载时IE发送给服务器的一些头信息。

GET http://192.168.100.100/download.zip HTTP/1.0
Range: bytes=822603-
Unless-Modified-Since: Sun, 26 Sep 2004 15:52:45 GMT
If-Range: "47febb2cfd76c41:2062"

　　这些头信息表明IE缓存了IIS提供的实体标签，并在If-Range头信息中把它发送回服务器了，这是确保下载从准确相同的文件恢复的一种途径。不幸的是，并非所有的浏览器的工作方式都相同。客户端发送的用于验证文件的其它HTTP头信息可能是If-Match、If-Unmodified-Since或者Unless-Modified-Since。很明显，该规范对于客户端软件必须支持哪些头信息，或者必须使用哪些头信息没有明确的规定。因此，有些客户端根本就没有使用头信息，而IE只使用If-Range和Unless-Modified-Since。你最好用代码检查这些信息。采用这种方式的时候，你的应用程序可以在非常高的层次遵循HTTP规范，并可以使用多种浏览器。Range头信息指明了被请求的字节范围--在例子中它是服务器应该恢复文件流的起始点。
　　　当IIS接收到恢复下载的请求类型时，它发回包含下面的头信息的响应信息：

HTTP/1.1 206 Partial Content
Content-Range: bytes 822603-2844010/2844011
Accept-Ranges: bytes
Last-Modified: Sun, 26 Sep 2004 15:52:45 GMT
ETag: "47febb2cfd76c41:2062"
Cache-Control: private
Content-Type: application/x-zip-compressed
Content-Length: 2021408

　　请注意上面的代码与最初的下载请求的HTTP响应有点差别--恢复下载的请求是206而最初下载的请求是200。这表明通过线路传递进来的内容是部分文件。这一次Content-Range头信息指出了被传递字节的精确数量和位置。

　　IE对于这些头信息是很挑剔的。如果最初的响应没有包含Etag头信息，IE永远不会尝试恢复下载。我测试过的其它客户端不使用ETag头信息，它们简单得依赖于文件名、请求范围，并使用Last-Modified头信息（如果它们试图验证该文件）。

　　深入了解HTTP协议

　　前面的部分中显示的头信息对于使恢复下载的解决方案运行来说是足够的，但是它没有完全覆盖HTTP规范。

　　在单个请求中，Range头信息可以询问多个范围，这种特性称为"多部分范围（multipart ranges）"。请不要与分段下载（segmented downloading）混淆，几乎所有的下载工具都使用分段下载来提高下载速度。这些工具声称通过打开两个或多个并发的连接（每个连接请求文件的不同范围）提高了下载速度。

　　多部分范围的想法并没有开启多个连接，但是它可以使客户端软件可以在单个请求/响应周期中请求某个文件的最前面的十个和最后面的