Home / server / Questions / 145844
In Process
Cruachan
Asked: 2010-05-28 05:06:30 +0800 CST

PDF download hanging from server with Firefox/Chrome

  • 772

I have a Windows 2008 R2 (virtual) server running a number of websites. My client has uploaded several PDFs by FTP to a download directory from where they can be retrieved via a web page.

This works fine in IE and Safari, but when attempting to download with Firefox or Chrome both browsers hang and Firefox posts 'stopped' in the status bar at the bottom of the page. We've tried this on several PCs at different locations so I think this might be a server problem - although conceivably the software used to generate the PDFs may have produced something incompatible with streaming to Firefox/Chrome.

Why reasons could there be to produce this behaviour? Is there some configuration setting I need to change?

EDIT: Checked headers with Firebug - a GET sticks with a 206 Partial Content

Content-Type    application/pdf
Last-Modified   Sun, 21 Mar 2010 19:50:49 GMT
Accept-Ranges   bytes
Etag    "42da4bce2fc9ca1:0"
Server  Microsoft-IIS/7.5
X-Powered-By    ASP.NET
Date    Thu, 27 May 2010 15:39:34 GMT
Content-Length  329532
Content-Range   bytes 27484-357015/357016
Request Headersview source
Host    www.caepost.co.uk
User-Agent  Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
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
Range   bytes=27484-357015,27484-27485
windows-server-2008 iis pdf

4 Answers

  1. IIS version 7.5 changed the way it responds to byte-range requests, such as those made by the Acrobat plugin. If the request is for a single contiguous range, IIS now reponds with the "Content-Range" header rather than "ContentType: multipart/byteranges" header, which is actually valid HTTP, but it confuses the Acrobat plugin.

    Adobe are currently working on a fix: http://kb2.adobe.com/cps/807/cpsid_80780.html

    And in the meantime, Microsoft have provided a hotfix to make IIS 7.5 go back to the old behaviour: http://support.microsoft.com/kb/979543

    • 4

  2. We upgraded servers and IIS 7.5 gave us this same issue. Checked the headers and confirmed the issue.

    Applied the hotfix http://support.microsoft.com/kb/979543 but that did not solve the problem. I think the difference here is that our site was running in classic mode. (Had to do this for another product (Imis) installed). So it seems the hotfix only works if your site is running on Integrated mode.

    In the end I had to write a handler to catch pdf document requests and change the response header.

    context.Response.ContentType = "application/pdf";
context.Response.TransmitFile(filePath);
context.Response.End();

    That did the trick.

    The sysmptoms were not just limited to Acrobat opening the documents. In our case google chrome was also hanging when it tried to open the pdf, regardless of what pdf reader you have.

    • 2

  3. Can you post the response headers being sent?

    Firebug Net panel:
    alt text
    (source: getfirebug.com)

    Headers view:
    alt text
    (source: getfirebug.com)

    • 1

  4. This could be due to compression settings in IIS 7.0.

    The request header contains the following:

    Accept-Encoding: gzip,deflate

    to indicate that the browser accepts compressed content.

    When you use:

    context.Response.TransmitFile(filePath);

    IIS looks at the content-type that is set, and decides whether to compress the response.

    Unfortunately IIS does not appear to add 

    Content-Encoding: gzip

    to the Response header, which means Firefox and Chrome can't determine whether the data is compressed or not.

    Disabling content compression in IIS should fix this but will affect the whole website. Also the suggestion of setting a content-type may work in some circumstances. IIS 7 decides whether to compress the response based on the mime-type.

    http://www.iis.net/configreference/system.webserver/httpcompression gives the following example to configure httpCompression in your ApplicationHost.config file:

    <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>

    Another option is to ensure 'Content-Encoding: gzip' is always added to the Response header, but you will need to be careful to ensure that the response really will be compressed, which it may not be for all content-types.

    • 0