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

Posted 2023-03-15

【中文标题】IIS 网站正在为 zip 文件发送多个内容类型的标头

【英文标题】：IIS website is sending multiple content-type headers for zip files

【发布时间】：2010-10-18 16:01:57

【问题描述】：

我们的 IIS5 服务器有问题。

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

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

但是，使用 Wireshark 对 HTTP 数据包的检查表明，对 zip 文件的请求返回 两个 Content-Type 标头。

内容类型：文本/html； charset=UTF-8 内容类型： application/x-zip-compressed

知道为什么 IIS 会发送 两个 内容类型的标头吗？常规 HTML 或图像文件不会发生这种情况。 ZIP 和 PDF 确实会发生这种情况。

我们可以要求 IIS 技术人员查看特定的位置吗？或者有没有我们可以检查的配置文件？

【问题讨论】：

这些文件是由 IIS 直接提供的，还是请求中涉及 ASP.NET 之类的东西？

据我所知，ASP.NET 不处理对 .ZIP 文件的请求。它们似乎直接由 IIS 提供服务。

您能列出任何 IIS 正在运行的 ISAPI 过滤器吗？ Context-Type 重新映射可能存在问题。

你在哪里运行wireshark？很有可能在 IIS 和添加内容类型标头的浏览器之间存在“透明”代理或类似服务。

我正在客户端机器上运行wireshark，它从Web服务器请求ZIP文件。

【参考方案1】：

我遇到过类似的问题。我在 IIS 6 上测试下载，但无法弄清楚为什么名为 test.zip 的压缩文件在 IE8 中显示为文本（在其他浏览器中很好，可以下载）。

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

我用更大的文件再次尝试，下载提示在 IE8 中显示正常。

可能与您的情况无关，但我想我会提到它。

提姆

【参考方案2】：

听起来您的 IIS 配置可能存在问题。但是，如果是这种情况，则无法从您的帖子中看出。

您可以在 IIS 的多个级别上配置 mime 类型。我的 IIS 5 知识有点生疏，据我所知，这种行为与 IIS 6 相同。我试图在 IIS 6 环境中模拟这一点，但根据接受的标头只收到一种 mime 类型

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

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

但是我觉得这证明不了太多。然而，它确实提出了一些问题：

服务器上设置的所有mime映射是什么（向服务器管理员询问metabase.xml文件，然后您可以确保他没有错过某些设置） 这些客户端是否在您控制的网络上？可能不会，我想知道您的服务器和客户端之间可能有什么代理服务器 IIS 日志的外观如何，对于该请求，我对 Accept 标头特别感兴趣。 我想知道fiddler 会显示什么？

【讨论】：

除非我记错了，iis5中没有metabase.xml。这是一个二进制文件，metabase.bin。

此外，使用 -headers 运行 tinyget 会产生与使用 Wireshark 发现的结果相同的结果：两个 Content-Type 标头。

【参考方案3】：

这可能与knowledge base article. 有关，这表明 IIS 可能正在压缩已经压缩的文件，但有些浏览器只是直接将错误数据传递给辅助应用程序（因为它已被压缩两次）。如果您将 zip 扩展的 mime 类型更改为 application/octet-stream，这可能不会发生。

【参考方案4】：

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

【参考方案5】：

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

【讨论】：

据我所知，没有使用 ISAPI 过滤器。

【参考方案6】：

我相信 - 我可能错了，http 1.1 标头发送多个标头定义并且最具体的具有优先级。

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

我已经通读了这个http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 并指出了你所说的内容 - 但不确定这是否是实际发生的事情。

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

【讨论】：

rfc 对此只字未提。并且不确定您是如何推断出 application/x-zip-commercial 比 text/html 更具体的。接受标头具有您所指的功能，在这种情况下 application/x-zip-commercial 比 application/* 更具体，而 / 是最不具体的。

就像我说的那样，我可能完全不在基地，如果很抱歉