| 网站首页 | 硬件维修 | 应用学院 | 网络组建 | 网站制作 | 菜鸟黑客 | 编程之道 | 数码大全 | 娱乐休闲 | 软件下载 | 在线视频 | 请您留言 | 技术论坛 | 
专 题 栏 目
最 新 热 门
最 新 推 荐
相 关 文 章
  • javascript模拟游戏中的…

  • javascript制作闪烁的边…

  • javascript制作浮动的工…

  • javascript设计漫天雪花

  • javascript设计网页中的…

  • 用javascript实现利用FL…

  • javascript实例教程(20)…

  • javascript实例教程(20)…

  • javascript实例教程(20)…

  • javascript实例教程(20)…

  • Q
    您现在的位置: 我是IT人 >> 网站制作 >> ASP.NET >> 文章正文
    在ASP.NET中跟踪和恢复大文件下载         
    在ASP.NET中跟踪和恢复大文件下载
    作者:网络 文章来源:转载 点击数: 更新时间:2005-8-10
    [ 字体:缩小 正常 放大 | 双击自动滚屏 ]
    请选择合适的字体颜色:

      下面的代码显示了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)混淆,几乎所有的下载工具都使用分段下载来提高下载速度。这些工具声称通过打开两个或多个并发的连接(每个连接请求文件的不同范围)提高了下载速度。

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

      诚实地说,我从来都没有找到使用这种特性软件片断。但是我拒绝在代码声明中写入"它并不是完全的HTTP兼容的"。略去这个特性必定会触犯墨菲法则(Murphy's Law)。无论如何,多部分范围还是被用于电子邮件传输中,把头信息、普通文本和附件分开。

      示例代码

      我们知道了客户端和服务器如何交换头信息以保证可恢复的下载,把这些知识与文件块流的思想结合起来,你就可以给自己的ASP.NET应用程序增加可靠的下载管理能力了。

      获取下载过程的控制权的方法是从客户端截取下载请求、读取头信息并适当地响应。在.NET之前,你必须编写ISAPI(Internet服务器API)应用程序来实现这种功能,但是.NET框架组件提供了一个IHttpHandler接口,在类中实现的时候,它允许你仅仅使用.NET代码就能够截取和处理请求。这意味着你的应用程序对于下载过程有完全控制权和响应性,再也不会涉及或使用IIS的自动化函数。

    上一页  [1] [2] [3] [4] [5] [6] 下一页  

    文章录入:小秦    责任编辑:小秦 
  • 上一篇文章:

  • 下一篇文章:
  • 发表评论】【加入收藏】【告诉好友】【打印此文】【关闭窗口
    网友评论:(只显示最新10条。评论内容只代表网友观点,与本站立场无关!)
    | 设为首页 | 加入收藏 | 联系站长 | 关于我们 | 友情链接 | 版权申明 |