使用Firefox / Chrome从服务器上下载PDF文件

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

我们升级服务器和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，无论你有什么PDF阅读器。

你能发布正在发送的响应头文件吗？

Firebugnetworking面板：

标题查看：

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

请求头包含以下内容：

 Accept-Encoding: gzip,deflate 

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

当你使用：

 context.Response.TransmitFile(filePath); 

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

不幸的是，IIS似乎没有添加

 Content-Encoding: gzip 

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

禁用IIS中的内容压缩应该解决这个问题，但会影响整个网站。 此外，设置内容types的build议可能在某些情况下起作用。 IIS 7决定是否压缩基于MIMEtypes的响应。

http://www.iis.net/configreference/system.webserver/httpcompression提供了下面的例子来configurationApplicationHost.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> 

另一个select是确保'Content-Encoding：gzip'总是被添加到Response头部，但是你需要小心确保响应真的会被压缩，这可能不是所有的内容types。