在IIS 7.5中提供PDF文件的问题

时间:2010-07-22 16:02:52

标签: iis pdf iis-7.5

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

我们的网络应用使用以下代码将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将显示在浏览器中。

但是,在IIS 7.5(Windows 7和Win 2008 R2)中,Foxit插件在IE中挂起,Adobe插件在IE和FF中挂起。即如果我进入

http://iis70Host/application/getPDF.aspx一切都很好,但是 <{1}}在同一个浏览器中挂起。

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

当它们崩溃时,我还没有设法从任一插件中获取有用的错误消息。

我认为IIS 7.5正在以某种方式破坏文件(因为客户端浏览器和插件是相同的) - 但我发现很难想象Web服务器如何变得错误(它只是流二进制文件)毕竟客户)。

  • 任何人都可以想到为什么这个行为会与IIS IIS 7.0和7.5不同?
  • 有谁知道如何从Adobe或foxit插件中获取更多调试信息? (如果我能得到他们崩溃的原因,那么也许它会给我一个关于服务器上出了什么问题的线索。)
  • 诊断问题的其他任何提示?

跟进

  • 我使用wget捕获了文件,它们相同

  • 我已经看过使用fiddler的请求和响应标头,他们没有明确提到响应头中的“Range”(或请求头中的Accept-range),这可能会对是mwalker建议的多部分请求问题。

  • 我继续安装了MS Hotfix,但这对情况没有帮助(因此 我更确定它不是“多部分问题”。)

所以我想我回来乞求更多关于可能出错的想法!

以下是fiddler访问运行IIS 7.5,7.0和6的主机时记录的请求和响应标头

IIS 7.5

http://iis75Host/application/getPDF.aspx

IIS 7.0

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 6

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

4 个答案:

答案 0 :(得分:6)

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

{这些论坛上的任何人都无法帮助解决这个问题,因为看起来我对问题的描述错了,并且没有说PDF插件是在IFrame中(一条信息是找到原因至关重要)。但无论如何要感谢尝试:)}

无论如何,这里的问题实际上似乎是: -

IF PDF插件位于IFrame AND 标题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上没有看到这个问题的原因似乎是IIS 6不尊重这个并且根本没有发送标题!

&LT;借口&GT;

我99%肯定这是问题:1%的疑问仍然是因为他无法在Firefox上重现问题(这是IE唯一的问题),他发现他可以在IIS 7和7.5上重现问题。

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

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

&LT; /借口&GT;

答案 1 :(得分:2)

我的预感是你遇到过这个:

您无法使用启用了Adobe PDF Reader插件的Web浏览器打开一些IIS 7.5托管的PDF文档
http://support.microsoft.com/kb/979543

多字节mojo!

您可以在代码中手动处理“多字节请求”吗?我在应用修补程序之前进行了调查。

如果您运行Fiddler,您是否看到来自Adobe(或Foxit)插件的多字节请求?

看起来可以从这里找到解决方案:

http://dotnetslackers.com/articles/aspnet/Range-Specific-Requests-in-ASP-NET.aspx

答案 2 :(得分:1)

从IIS / 7.5在IE中打开PDF的问题的另一个潜在原因是在Internet Explorer中禁用了HTTP / 1.1。请参阅http://chentiangemalc.wordpress.com/2012/02/16/case-of-the-disappearing-pdf/

答案 3 :(得分:0)

I had similar issue, after many different tries to fix the problem ended up being that the server was sending parts of the response content before it was totally complete(which you don't want in a PDF file especially if you are using Chrome pdf viewer, and I would say on any other file other than html/css/js etc). So just added this to the response and the problem was solved:

matplotlib.pyplot.stackplot(X, *revDataValues,
    linewidth=1.0,
    edgecolor='black')

matplotlib.pyplot.legend(revNames,
    loc=6, bbox_to_anchor=(1.05, 0.5),
    labelspacing=-2.5, frameon=False,         # reverse legend
    fontsize=9.0)