Fatal编程技术网
  • iis/
  • IIS网站正在为zip文件发送多个内容类型标题

IIS网站正在为zip文件发送多个内容类型标题

iis

IIS网站正在为zip文件发送多个内容类型标题,iis,zip,content-type,mime-types,iis-5,Iis,Zip,Content Type,Mime Types,Iis 5,我们的IIS5服务器有问题 当某些用户/浏览器单击下载.zip文件时，浏览器窗口中有时会呈现二进制乱码文本。所需的行为是下载文件或使用相关的zip应用程序打开文件 最初，我们怀疑文件上设置了错误的内容类型头。IIS技术人员确认IIS正在为mime类型为“application/x-zip-compressed”的.zip文件提供服务 然而，使用Wireshark检查HTTP数据包发现，对zip文件的请求返回两个内容类型头 内容类型：text/html； 字符集=UTF-8 内容类型： 应用程序

我们的IIS5服务器有问题

当某些用户/浏览器单击下载.zip文件时，浏览器窗口中有时会呈现二进制乱码文本。所需的行为是下载文件或使用相关的zip应用程序打开文件

最初，我们怀疑文件上设置了错误的内容类型头。IIS技术人员确认IIS正在为mime类型为“application/x-zip-compressed”的.zip文件提供服务

然而，使用Wireshark检查HTTP数据包发现，对zip文件的请求返回两个内容类型头

  • 内容类型：text/html； 字符集=UTF-8
  • 内容类型： 应用程序/x-zip-compressed
知道IIS为什么发送两个内容类型头吗？这不会发生在常规HTML或图像文件中。它确实发生在ZIP和PDF中

有没有什么地方可以让IIS技术人员查看？或者我们可以检查配置文件吗？

我相信——我可能错了，http 1.1头发送多个头定义，而最具体的头具有优先权

因此，在您的示例中，它发送2个text/html，然后是application/x-zip-commercial，因此第二个将是最具体的-如果无法在客户端上处理，则使用更通用的一个（本例中的第一个）——

我已经通读了你所说的这几点，但不确定这是否真的发生了

当然，我在这里可能完全错了

请确保没有设置任何ISAPI过滤器或ASP.net HTTP模块来重写标头。如果他们不检查标题是否已经存在，则将追加而不是替换标题。不久前，我们遇到内部身份验证模块无法正确更新标头的问题，因此我们得到了两个授权标头，一个来自IIS，另一个来自我们的模块。

服务器上安装了什么软件来处理.zip文件？
如果IIS从注册表中获取MIME翻译，可能您使用的zip软件已经注册了MIME类型。这并不能解释为什么IIS会使用两个内容类型头进行响应，因此任何ISAPI筛选器和其他Mime表都是可疑的。

这可能与此有关。这表明IIS可能正在压缩已经压缩的文件，但一些浏览器只是直接向提供坏数据的辅助应用程序推卸责任（因为它已经压缩了两次）. 如果将zip扩展的mime类型更改为application/octet流，则可能不会发生这种情况

听起来您的IIS配置可能有问题。然而，这是不可能从你的帖子，如果这是事实

您可以在IIS的多个级别上配置mime类型。我的IIS 5知识有点生疏，据我记忆所及，IIS 6的这种行为也是一样的。我试图在IIS6环境中模拟这种情况，但根据接受的头，只收到一种mime类型

我已将站点上zip文件的标题设置为application/x-zip-compressed，并将文件的标题设置为explicity

tinyget -srv:dev.24.com -uri:/helloworld.zip -tbLoadSecurity
WWWConnect::Connect("server.domain.com","80")
IP = "127.0.0.1:80"
source port: 1581

REQUEST: **************
GET /helloworld.zip HTTP/1.1
Host: server.domain.com
Accept: */*


RESPONSE: **************
HTTP/1.1 200 OK
Content-Length: 155
Content-Type: text/html
Last-Modified: Wed, 29 Apr 2009 08:43:10 GMT
Accept-Ranges: bytes
ETag: "747da786a6c8c91:0"
Server: Microsoft-IIS/6.0
Date: Wed, 29 Apr 2009 10:47:10 GMT

PK??
?   ?   ?   helloworld.txthello worldPK??¶
?   ?   ?       ?         helloworld.txtPK??    ? ? <   7   ? hello world sample
WWWConnect::Close("server.domain.com","80")
closed source port: 1581

tinyget-srv:dev.24.com-uri:/helloworld.zip-tbLoadSecurity
WWWConnect:：Connect（“server.domain.com”、“80”）
IP=“127.0.0.1:80”
源端口：1581
请求：**************
GET/helloworld.zip HTTP/1.1
主机：server.domain.com
接受：*/*
答复：**************
HTTP/1.1200ok
内容长度：155
内容类型：text/html
最后修改：2009年4月29日星期三08:43:10 GMT
接受范围：字节
ETag:“747da786a6c8c91:0”
服务器：Microsoft IIS/6.0
日期：2009年4月29日星期三10:47:10 GMT
PK？？
?   ?   ?   helloworld.txthello worldPK
?   ?   ?       ?         helloworld.txtPK？？？<7.你好，世界样本
WWWConnect:：Close（“server.domain.com”、“80”）
封闭源端口：1581
然而，我觉得这证明不了什么。然而，它确实提出了几个问题：

  • 服务器上设置的所有mime映射是什么（向服务器管理员询问metabase.xml文件，然后您可以确保他没有错过某些设置）
  • 这些客户端是否在您控制的网络上？可能不是，我想知道在您的服务器和客户端之间可能有什么代理服务器
  • IIS日志的外观如何，对于该请求，我特别感兴趣的是Accept头
  • 我想知道会显示什么
    我也遇到过类似的问题。我在IIS 6上测试下载，不明白为什么一个名为test.zip的压缩文件在IE8中显示为文本（在其他浏览器中可以下载）

    然后我意识到为了测试我压缩了一个非常小的文本文件。我的猜测是IE嗅探了文件，看到了文本（由于大小较小，文本几乎没有压缩），并确定它是纯文本

    我用一个更大的文件再试了一次，下载提示在IE8中显示为OK

    可能与你的案子无关，但我想我会提到的

    Tim

    这些文件是由IIS直接提供的，还是请求中涉及类似ASP.NET的内容？据我所知，ASP.NET没有处理.ZIP文件的请求。它们似乎直接由IIS提供服务。您能否列出IIS正在运行的任何ISAPI筛选器？上下文类型重新映射可能有问题。您在哪里运行wireshark？IIS和添加内容类型标头的浏览器之间可能存在“透明”代理或类似服务。我正在从web服务器请求ZIP文件的客户端计算机上运行wireshark。rfc对此没有说明。并且不确定您如何推断application/x-zip-commercial比text/html更具体。Accept标头具有您所指的功能，在这种情况下，application/x-zip-commercial比application/*和