3

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
Cruachan
  • 429
  • 1
  • 9
  • 17

4 Answers4

4

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

Joe Daley
  • 151
  • 1
  • 3
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.

Vince T
  • 81
  • 6
1

Can you post the response headers being sent?

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

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

Glorfindel
  • 1,213
  • 3
  • 15
  • 22
David Murdoch
  • 492
  • 6
  • 19
  • Where would I find those? Sorry - I'm a developer rather than a sysadmin and I just maintain the server for a few client's systems – Cruachan May 27 '10 at 13:43
  • Download [firebug](http://getfirebug.com/) for firefox and use the net panel and the "Persist" button to view the headers. – David Murdoch May 27 '10 at 14:25
  • You may also be able to do this in Chrome. Press Ctrl+Shift+i, open the resources panel, enable resource tracking, (re)load your PDF, view headers. – David Murdoch May 27 '10 at 14:35
  • Firebug reports two GETs, the first returns 200 OK, the second a 206 Partial Content - posted as an edit above. – Cruachan May 27 '10 at 15:42
  • hm, I've never noticed the Range and Content-Range headers before. You may want to look at the [Content-Range spec](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.16) (note: I'm not really sure if Content-Range is causing a problem). You may want to try your luck on [stackoverflow](http://www.stackoverflow.com)...although they may just send you back here...just try to make it sound programming-related. – David Murdoch May 27 '10 at 16:50
0

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.

user2466466
  • 1