这个补丁引入了TransmitFile方法，它把一个磁盘文件读入到较小的内存缓冲区之后就开始传输该文件。尽管这个方案解决了内存和循环的问题，但是它仍然不能令人满意。你不能控制响应的生命周期。你无法知道下载是否正确地完成了，你没有办法知道下载是否被中断了，并且（如果你建立了临时文件）你也不知道是否应该、以及什么时候可以删除这些文件。更糟的是，如果下载的确失败了，TransmitFile方法又从客户端下次尝试的文件头部开始下载。

　　其中一种可能的解决方案--实现后台智能传输服务（BITS）对于多数站点来说是不可行的，因为这会毁掉维持客户端浏览器和操作系统独立性而作出的努力。

　　令人满意的解决方案的基础还是来自微软用于解决WriteFile引起的内存混乱问题的第一次尝试（见知识库文章812406）。那篇文章演示了智能的大块数据下载过程，它从文件流中读取数据。在服务器把字节块发送给客户端之前，它使用Response.IsClientConnected属性检查客户端是否仍然保持着连接。如果仍然保持连接，它就继续发送流字节，否则就停止，以防止服务器发送不必要的数据。
这就是我们采用的方法，特别是在下载临时文件的时候。在IsClientConnected返回False的情况下，你就知道下载过程被中断了，你应该保存文件；反之，当这个过程成功完成的时候，你就删除临时文件。此外，为了恢复中断了的下载，你需要做的工作是从上次下载尝试过程中客户端连接失败的文件点开始下载。

　　HTTP协议和头信息（Header）支持

　　HTTP协议支持可以用于处理被中断下载的头信息。使用少量的HTTP头信息，你可以增强自己的下载过程，使它完全遵循HTTP协议规范。这个规范与ranges一起提供恢复被中断的下载所需要的一切信息。

　　下面是它的工作方式。首先，如果服务器支持客户端断点续传，它就在初始的响应中发送Accept-Ranges头信息。服务器还发送一个实体标签（entity tag）头信息（ETag），它包含一个唯一的标识字符串。

(编辑:aniston)