Issues delivering PDF files in IIS 7.5_问答_开发者

This is a very wierd issue - any thoughts/help/hints would be greatly appreciated.

Our web app streams PDF files to the browser using the following code

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();

Which seems pretty innocuous and works fine in IIS 6 and IIS 7: if the user has a PDF plugin installed (adobe or foxit etc.) then the PDF is displayed in their browser.

However, in IIS 7.5 (Windows 7 and Win 2008 R2), the Foxit plugin hangs in IE and the Adobe plugin hangs in IE and FF. i.e. if I enter

http://iis70Host/application/getPDF.aspx everything is fine but http://iis75Host/application/getPDF.aspx in the same browser hangs.

I am serving up exactly the same PDF file to exactly the same browsers and both web servers are running the app in the 2.0 framework.

I have not yet managed to get a useful error message out of either plugin when they crash.

I am left thinking that IIS 7.5 is corrupting the file somehow (because the client browser and plugin are the same) - but I find it really hard to imagine how the web server could get thins wrong (it is only streaming binary to the client after all).

Can anyone think of why the behaviour would be different twix IIS 7.0 and 7.5?
Does anyone know how to get more debug information out of either the Adobe or foxit plugin? (if I could get the reason why they are crashing, then maybe it will give me a clue as to what is going wrong on the server).
Any other tips for diagnosing the problem?

Follow ups

I have captured the files using wget and they are identical.
I have had a look at the request and response headers using fiddler and they make no explicit mention of "Range" in the response header (or Accept-range in the request header), which lessons the likelihood that this is the multi-part request problem as suggested by mwalker.
I went ahead and installed the MS Hotfix anyway and that did not help the situation (thus I am even more sure that it is not a "multi-part problem").

So I think I am back to begging for more ideas as to what could be going wrong!

Below are the request and response headers that fiddler records when accessing hosts running IIS 7.5, 7.0 and 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, 2开发者_运维技巧6 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

OK. A work colleague finally figured this out.

{There is no way that anyone on these forums could have helped with this because it looks like I got the description of the problem wrong and didn't say that the PDF plugin is inside an IFrame (a piece of information which was vital to finding the cause). But thanks for trying anyway :) }

Anyways, here what the problem actually appears to be: -

IF the PDF plugin is in an IFrame AND the header X-UA-Compatible: IE=8 is present, then the plugin crashes in IE.

Our solution was simply to remove the X-UA-Compatible: IE=8 header. This header was put in a while back as a quick fix to fix up some IE rendering issues but we have since re-wrote the HTML + CSS and it is now superfluous). It was included in the web.config like so

   <httpProtocol>
          <customHeaders>
              <clear />
              <add name="X-UA-Compatible" value="IE=8" />
          </customHeaders>
      </httpProtocol>

The reason why we did not see this problem on IIS6 seems to be that IIS 6 does not honor this and simply did not send the header!

I am 99% sure that this is the problem: a 1% doubt remains because he could not reproduce the problem on Firefox (it was an IE only problem) and he found that he could reproduce the problem on IIS 7 and 7.5.

But I sat down and watched him reproduce the bug and fix it and so either a) my old machine was cursed or b) I was just an idiot when looking at the bug to start off with and got confused. You decide. I did not mention that the plugin was inside an IFrame because I wrongly assumed that this was an unrelated detail.

[The machine on which I first experimented with this bug has since been turned into a build server so I can not go back to that and see if I can reproduce on Firefox ]

</excuses>

My hunch is that you've encountered this:

You cannot open some IIS 7.5-hosted PDF documents by using a Web browser that has the Adobe PDF Reader plug-in enabled
http://support.microsoft.com/kb/979543

Multi-byte mojo!

You might be able to manually handle the "multi-byte request" in your code? I'd investigate that before applying a hotfix.

If you run Fiddler, do you see the multi-byte request coming from the Adobe (or Foxit) plugin?

Looks like there could be a solution from here:

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

Another potential cause of issues opening PDFs in IE from IIS/7.5 is when HTTP/1.1 is disabled in Internet Explorer. Refer to http://chentiangemalc.wordpress.com/2012/02/16/case-of-the-disappearing-pdf/

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: