☰

使用 Firefox/Chrome 下载 PDF 时服务器挂起

tag-icon • tag-icon windows-server-2008 iis pdf
使用 Firefox/Chrome 下载 PDF 时服务器挂起

我有一台 Windows 2008 R2（虚拟）服务器，运行多个网站。我的客户已通过 FTP 将多个 PDF 上传到下载目录，客户可以通过网页从该目录检索这些 PDF。

在 IE 和 Safari 中，此方法运行良好，但尝试使用 Firefox 或 Chrome 下载时，两种浏览器都会挂起，并且 Firefox 会在页面底部的状态栏中显示“已停止”。我们在不同地点的几台电脑上尝试过此方法，因此我认为这可能是服务器问题 - 虽然可以想象，用于生成 PDF 的软件可能产生了与流式传输到 Firefox/Chrome 不兼容的内容。

为什么会产生这种行为？我需要更改某些配置设置吗？

编辑：使用 Firebug 检查标头 - GET 坚持 206 部分内容

Content-Type    application/pdf
Last-Modified   Sun, 21 Mar 2010 19:50:49 GMT
Accept-Ranges   bytes
Etag    "42da4bce2fc9ca1:0"
Server  Microsoft-IIS/7.5
X-Powered-By    ASP.NET
Date    Thu, 27 May 2010 15:39:34 GMT
Content-Length  329532
Content-Range   bytes 27484-357015/357016
Request Headersview source
Host    www.caepost.co.uk
User-Agent  Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-gb,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive  115
Connection  keep-alive
Range   bytes=27484-357015,27484-27485

答案1

IIS 7.5 版改变了其响应字节范围请求（例如 Acrobat 插件发出的请求）的方式。如果请求针对单个连续范围，IIS 现在将使用“Content-Range”标头而不是“ContentType: multipart/byteranges”标头进行响应，这实际上是有效的 HTTP，但它会使 Acrobat 插件感到困惑。

Adobe 目前正在努力修复：http://kb2.adobe.com/cps/807/cpsid_80780.html

与此同时，微软提供了一个修补程序，使 IIS 7.5 恢复到以前的行为：http://support.microsoft.com/kb/979543

答案2

我们升级了服务器，但 IIS 7.5 也出现了同样的问题。检查了标头并确认了问题。

应用修补程序http://support.microsoft.com/kb/979543但这并没有解决问题。我认为这里的区别在于我们的网站是在经典模式下运行的。（必须对安装的另一个产品（Imis）执行此操作）。因此，似乎只有当您的网站在集成模式下运行时，此修补程序才有效。

最后我不得不编写一个处理程序来捕获 pdf 文档请求并更改响应标头。

context.Response.ContentType = "application/pdf";
context.Response.TransmitFile(filePath);
context.Response.End();

这招很管用。

症状不仅限于 Acrobat 打开文档。在我们的案例中，无论你使用什么 pdf 阅读器，google chrome 在尝试打开 pdf 时也会挂起。

答案3

您可以发布正在发送的响应头吗？

Firebug 网络面板：
替代文本
（来源：getfirebug.com）

标题视图：
替代文本
（来源：getfirebug.com）

答案4

这可能是由于 IIS 7.0 中的压缩设置造成的。

请求标头包含以下内容：

Accept-Encoding: gzip,deflate

表明浏览器接受压缩内容。

使用时：

context.Response.TransmitFile(filePath);

IIS 查看设置的内容类型，并决定是否压缩响应。

不幸的是 IIS 似乎没有添加

Content-Encoding: gzip

到响应头，这意味着 Firefox 和 Chrome 无法确定数据是否被压缩。

在 IIS 中禁用内容压缩应该可以解决这个问题，但会影响整个网站。此外，在某些情况下，设置内容类型的建议可能有效。IIS 7 根据 mime 类型决定是否压缩响应。

http://www.iis.net/configreference/system.webserver/httpcompression给出了在 ApplicationHost.config 文件中配置 httpCompression 的示例：

<httpCompression
      directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files">
   <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
   <dynamicTypes>
      <add mimeType="text/*" enabled="true" />
      <add mimeType="message/*" enabled="true" />
      <add mimeType="application/javascript" enabled="true" />
      <add mimeType="*/*" enabled="false" />
   </dynamicTypes>
   <staticTypes>
      <add mimeType="text/*" enabled="true" />
      <add mimeType="message/*" enabled="true" />
      <add mimeType="application/javascript" enabled="true" />
      <add mimeType="*/*" enabled="false" />
   </staticTypes>
</httpCompression>

另一个选择是确保“Content-Encoding：gzip”始终添加到响应标头，但您需要小心确保响应确实会被压缩，但对于所有内容类型来说可能并非如此。

相关内容