当IIS接收到恢复下载的请求类型时,它发回包含下面的头信息的响应信息:HTTP/1.1 206 Partial ContentContent-Range: bytes 822603-2844010/2844011Accept-Ranges: bytesLast-Modified: Sun, 26 Sep 2004 15:52:45 GMTETag: "47febb2cfd76c41:2062"Cache-Control: privateContent-Type: application/x-zip-compressedContent-Length: 2021408 请注意上面的代码与最初的下载请求的HTTP响应有点差别--恢复下载的请求是206而最初下载的请求是200。这表明通过线路传递进来的内容是部分文件。这一次Content-Range头信息指出了被传递字节的精确数量和位置。 IE对于这些头信息是很挑剔的。如果最初的响应没有包含Etag头信息,IE永远不会尝试恢复下载。我测试过的其它客户端不使用ETag头信息,它们简单得依赖于文件名、请求范围,并使用Last-Modified头信息(如果它们试图验证该文件)。 深入了解HTTP协议 前面的部分中显示的头信息对于使恢复下载的解决方案运行来说是足够的,但是它没有完全覆盖HTTP规范。 在单个请求中,Range头信息可以询问多个范围,这种特性称为"多部分范围(multipart ranges)"。请不要与分段下载(segmented downloading)混淆,几乎所有的下载工具都使用分段下载来提高下载速度。这些工具声称通过打开两个或多个并发的连接(每个连接请求文件的不同范围)提高了下载速度。 多部分范围的想法并没有开启多个连接,但是它可以使客户端软件可以在单个请求/响应周期中请求某个文件的最前面的十个和最后面的十个字节。 诚实地说,我从来都没有找到使用这种特性软件片断。但是我拒绝在代码声明中写入"它并不是完全的HTTP兼容的"。略去这个特性必定会触犯墨菲法则(Murphy's Law)。无论如何,多部分范围还是被用于电子邮件传输中,把头信息、普通文本和附件分开。
(编辑:aniston)
·2024年12月目录 ·2024年11月目录 ·2024年10月目录 ·2024年9月目录 ·2024年8月目录 ·2024年7月目录 ·2024年6月目录 ·2024年5月目录 ·2024年4月目录 ·2024年3月目录 ·2024年2月目录 ·2024年1月目录 ·2023年12月目录 ·2023年11月目录