All geek questions in one place

Problems Delivering PDF Files in IIS 7.5

This is a very strange problem - we will be grateful for any thoughts / hints / tips.

Our web application transfers 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 harmless and works fine in IIS 6 and IIS 7: if the user has the PDF plugin installed (adobe or foxit, etc.), then the PDF file is displayed in the 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. those. if i introduce

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

I serve the exact same PDF file in exactly the same browsers, and both web servers run the application in 2.0 environment.

I have not yet been able to get a useful error message from any plugin when they fail.

It remains for me to think that IIS 7.5 somehow distorts the file (because the client browser and the plugin are the same), but it is very difficult for me to imagine how the web server can be wrong (it is only a streaming binary client in the end).

  • Can anyone think why the behavior will be different from twix IIS 7.0 and 7.5?
  • Does anyone know how to get more debugging information from an Adobe or foxit plugin? (if I could understand why they crash, perhaps this will let me understand what is happening on the server).
  • Any other tips for diagnosing the problem?

Following actions

  • I captured the files using wget and they are identical.

  • I looked at the request and response headers using a violinist, and they do not explicitly mention “Range” in the response header (or Accept-range in the request header), which explains the likelihood that this is a problem of the multi-part request proposed by mwalker.

  • I went and installed MS Hotfix anyway, and that didn’t help the situation (so I’m even sure that this is not a “multi-part problem”).

So, I think I'll get back to begging for more ideas on what could go wrong!

The following are the request and response headers that the script writes 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, 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
+4
source share
4 answers

OK In the end, a work colleague realized this.

{There is no way that any of these forums could help with this, because it looks like I misrepresented the problem and did not say that the PDF plugin is inside the IFrame (part of the information that was vital to finding the cause). But thanks for trying anyway :)}

In any case, here is what the problem really is: -

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

Our solution was to simply remove the X-UA-Compatible: IE=8 header X-UA-Compatible: IE=8 . This title was put in some time as a quick fix to fix some problems with IE rendering, but since then we have re-written HTML + CSS, and now it is superfluous). It was included in the web.config file so

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

The reason we did not see this problem in IIS6 seems to be because IIS 6 does not respect this and simply does not send the header!

<positions>

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

But I sat down and watched how he reproduces the error and fixes it, and so: a) my old car was damned or b) I was just an idiot when I looked at the error to start with it and got confused. You decide. I did not mention that the plugin is inside an IFrame, because I mistakenly thought it was an unrelated part.

[The machine on which I first experimented with this error has since turned into a build server, so I cannot go back to this and see if I can play back on Firefox]

</ prepositions>

+6
source

I suspect you came across this:

You cannot open some PDF documents with IIS 7.5 support using a web browser with the Adobe PDF Reader plugin enabled http://support.microsoft.com/kb/979543

Multibyte mojo!

Perhaps you can manually handle the "multibyte request" in your code? I would investigate this before applying the fix.

If you run Fiddler, do you see a multibyte request coming from an Adobe (or Foxit) plugin?

It looks like there might be a solution here:

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

+2
source

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

+1
source

I had a similar problem, after many attempts to fix the problem ended up with the server sending parts of the content of the response before it was completely completed (which you don’t want in the PDF file, especially if you use the Chrome pdf viewer, and I would say that in any other file except html / css / js etc.). So just added this to the answer and the problem was resolved:

 Response.BufferOutput= true;
0
source

Source: https://habr.com/ru/post/1316566/

More articles:


All Articles