IIS 7.5中交付PDF文件的问题

这是一个非常棘手的问题-任何想法/帮助/提示都将不胜感激

我们的web应用程序使用以下代码将PDF文件流式传输到浏览器

byte [] fileBytes = GetTheFileBytes();
string contentType = "application/pdf";

context.Response.Clear();
context.Response.ClearHeaders();
context.Response.ContentType = contentType;
context.Response.AddHeader("Content-Length", fileBytes.Length.ToString());
context.Response.AddHeader("Content-Type", contentType);

MemoryStream outputStream = new MemoryStream(fileBytes);
outputStream.WriteTo(context.Response.OutputStream);
context.Response.Flush();

这看起来很无害，在IIS 6和IIS 7中也可以正常工作：如果用户安装了PDF插件（adobe或foxit等），则PDF将显示在他们的浏览器中

然而，在IIS7.5（Windows7和Win2008R2）中，Foxit插件挂在IE中，Adobe插件挂在IE和FF中。i、 如果我进去

http://iis70Host/application/getPDF.aspx

一切正常，但

http://iis75Host/application/getPDF.aspx

在同一浏览器中挂起

我正在为完全相同的浏览器提供完全相同的PDF文件，并且两个web服务器都在2.0框架中运行该应用程序

当这两个插件崩溃时，我还没有从中得到有用的错误消息

我一直认为IIS 7.5以某种方式破坏了文件（因为客户端浏览器和插件是相同的）-但我发现很难想象web服务器怎么会出错（毕竟它只是将二进制文件流式传输到客户端）

• 有人能想到为什么twix IIS 7.0和7.5的行为会有所不同吗
• 有人知道如何从Adobe或foxit插件中获取更多调试信息吗？（如果我能知道它们崩溃的原因，那么它可能会给我一个关于服务器上出了什么问题的线索）
• 还有其他诊断问题的提示吗

---

后续行动

• 我使用wget捕获了这些文件，它们是相同的

• 我使用fiddler查看了请求和响应头，它们在响应头中没有明确提到“范围”（或在请求头中提到接受范围），这说明了这可能是mwalker建议的多部分请求问题

• 无论如何，我还是继续安装了MS修补程序，但这对情况没有帮助（因此 我更确信这不是一个“多部分问题”）

因此，我想我又回到了乞求更多的想法，以什么可能会出错

下面是fiddler在访问运行IIS 7.5、7.0和6的主机时记录的请求和响应头

IIS 7.5

GET /eco/dataFile.aspx?data=147098&record=9754 HTTP/1.1
Host: chrisf
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.7) Gecko/20100713 Firefox/3.6.7
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
Referer: http://chrisf/eco/embeddedMedia.aspx?record=9754&search=true
Cookie: CC=test; 

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 114340
Content-Type: application/pdf
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
Persistent-Auth: true
X-UA-Compatible: IE=8
Date: Mon, 26 Jul 2010 12:47:46 GMT

IIS 7.0

GET /eco/dataFile.aspx?data=147098&record=9754 HTTP/1.1
Host: chris1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.7) Gecko/20100713 Firefox/3.6.7
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
Referer: http://chrisf/eco/Test1.htm
Cookie: CC=test; 

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 114340
Content-Type: application/pdf
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
X-UA-Compatible: IE=8
Date: Mon, 26 Jul 2010 12:17:15 GMT

IIS 6

GET /mi/dataFile.aspx?data=147098&record=9754 HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: http://mi-dev/mi/embeddedMedia.aspx?record=9754&search=true
Accept-Language: en-GB
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)
Accept-Encoding: gzip, deflate
Host: mi-dev
Connection: Keep-Alive
Cookie: CC=test; 
Authorization: Negotiate YII...

HTTP/1.1 200 OK
Date: Mon, 26 Jul 2010 10:37:47 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oYGg...
X-AspNet-Version: 2.0.50727
Content-Length: 114340
Cache-Control: private
Content-Type: application/pdf

---

我的直觉是你遇到过这样的情况：

无法使用启用了Adobe PDF Reader插件的Web浏览器打开某些IIS 7.5托管的PDF文档

多字节魔咒

您是否可以手动处理代码中的“多字节请求”？在应用修补程序之前，我会对此进行调查

如果您运行Fiddler，您是否看到来自Adobe（或Foxit）插件的多字节请求

看起来这里可能有一个解决方案：

---

好的。一位同事终于明白了这一点

{这些论坛上的任何人都无法对此提供帮助，因为看起来我对问题的描述是错误的，并且没有说PDF插件位于IFrame（一条对于找到原因至关重要的信息）中。但是无论如何，感谢您的尝试：）}

不管怎么说，问题实际上是这样的：-

如果PDF插件位于IFrame中，并且标题

X-UA-Compatible:IE=8

存在，则插件在IE中崩溃

我们的解决方案只是删除

X-UA-Compatible:IE=8

头。这个标题是在不久前作为一个快速修复来修复一些IE渲染问题的，但是我们已经重新编写了HTML+CSS，现在它是多余的）。它包含在web.config中，如下所示

<httpProtocol> <customHeaders> <clear /> <add name="X-UA-Compatible" value="IE=8" /> </customHeaders> </httpProtocol> 我们没有在IIS6上看到这个问题的原因似乎是IIS6不遵守这一点，只是没有发送标题

我99%确信这就是问题所在：1%的怀疑仍然存在，因为他无法在Firefox上重现这个问题（这是一个仅限于IE的问题），并且他发现他可以在IIS 7和7.5上重现这个问题

但是我坐下来看着他复制这个bug并修复它，所以要么a）我的旧机器被诅咒了，要么b）当我一开始看到这个bug时，我只是个白痴，然后感到困惑。由你决定。我没有提到插件在IFrame中，因为我错误地认为这是一个无关的细节

[我第一次尝试这个bug的机器已经变成了一个构建服务器，所以我不能回到那个机器上，看看是否可以在Firefox上重现]

---

从IIS/7.5在IE中打开PDF时出现问题的另一个潜在原因是Internet Explorer中禁用了HTTP/1.1。参考

我也遇到过类似的问题，在多次尝试解决问题后，问题的最终结果是服务器在响应内容完全完成之前发送了部分内容（您不希望在PDF文件中发送响应内容，尤其是在使用Chrome PDF viewer的情况下，我想说的是在html/css/js等文件之外的任何其他文件中）。 因此，在回答中添加了这一点，问题就解决了：

Response.BufferOutput= true; 

---

使用命令行下载程序从web服务器获取文件并进行比较。wget是我的最爱。此处提供：。使用firebug查看发送的头并进行比较。答案必须是这两种情况中的一种不同。让我们知道您发现了什么。您将保存响应流，而不是直接在浏览器中查看？你有有效的PDF文件吗？您是否使用数据包嗅探器（或类似工具）来比较从两个不同服务器获得的标题和响应？为什么要设置两次内容类型？context.Response.ContentType=ContentType；应该足够了。IIS 7.5响应有一个“Persistent auth:true”头。这件事会发生吗