Issues opening PDF files in IE9 from Sitecore Media Library

tl;dr A bug in the Adobe Reader plugin causes IE9 to not load PDF files in the browser, which can be fixed by disabling chunked transfer encoding in Sitecore config.

About 5 months ago we upgraded a Sitecore 6.4 solution to 7.0. I can’t remember why we didn’t go with 7.1 since it had been released, but I think it may have been because some of the modules we were using (mainly WFFM and ECM) were not ready at the time. Regardless, the issue we faced would have been the same.

The site we were working on was very media heavy – lots of images and PDFs (in fact this was an ideal candidate for CDN, but that’s another story…). During testing we were getting reports of the links to PDF’s no longer working, but intermittently and only for some people. Eventually we narrowed it down to IE9 browsers only.

Testing with older versions of Internet Explorer

Most of us were running IE11 by this stage, so kind of difficult to track down a bug if you can’t replicate the issue. Luckily Microsoft have kindly provided us all with some Virtual Machine images on various OS’s with different versions of Internet Explorer. There are even some Mac and Linux variants. You can download them from the modern.ie website.

Investigation

So on with the investigation… except as soon as I tried the problematic links in IE9 they all worked perfectly for me. Same in Chrome and Firefox (but this was never an issue). Mmmm. I tried on a few different PDF files on my local machine and bingo, I was able to replicate the issue. But if I closed the browser and tried the same link again it worked!

Knowing that Sitecore caches all files to disk before serving from the DB I tried to open up the PDF files directly from disk in Adobe Reader, and there were no issues with the files. So I deleted the MediaCache folder, tried again then the error appeared every time I opened an non-cached file. So there was some sort of issue with the media being streamed directly from the database to IE9 browsers…

Looking at Fiddler I could see that the file was being streamed in chunks which were repeatedly being downloaded. Opening the media URL directly in Adobe Reader was working fine (Chrome and Firefox use their own built in reader rather than the Adobe plugin). The caveat here was that if I started Fiddler and tried to down the file it worked perfectly. If I started the download and then started Fiddler I could see the repeated downloads of the chunks. Fiddler was acting as the middle man and circumventing the issue. Incidently, Firefox and Chrome did not chunk the file and instead downloaded the whole thing.

Sitecore Recommended Fix

Since we were short on time at the time I fixed the issue by setting forceDownload=true for the PDF media type in config.

<!-- Force download of PDF files -->
<mediaLibrary>
  <mediaTypes>
	<mediaType name="PDF file" extensions="pdf">
	  <forceDownload>true</forceDownload>
	</mediaType>
  </mediaTypes>
</mediaLibrary>

We raised a ticket with Sitecore and they gave us the same workaround. In fact, in Sitecore 7.2 this setting was made default (see release notes):

Media requests
Some browsers had problems downloading and opening PDF files with the default Sitecore configuration. This has been fixed by changing the element to true for the element in the web.config file. (368967)

It wasn’t ideal, but it wasn’t a showstopper either. We had other areas in the site where the user was asked to download files anyway (high res images, installation manuals etc).

Alternative solution

This bug came up again recently on a question on SDN forum and an answer from Sandeepkumar Gupta pointed us to a blog post by Rick Matherly on the same issue and a config setting which would load the PDF in the browser window iteself:

<setting name="Media.EnableRangeRetrievalRequest" value="false"/>

I obviously had not Googled with the correct search terms the first time round since this post was from July 2012.

Chunked Transfer Encoding

So what was going on? It seems like it is an issue with PDFs and IE9 in general, nothing to do with Sitecore or the way it streams its media: Problem Downloading Large PDF Files In Internet Explorer

The culrpit is chunked transfer encoding, which is exactly what the above setting switches off, and a bug in the Adobe Reader plugin and IE9 compatibility. This was added in Sitecore 6.5, so we never noticed the issue previously.

protected virtual bool DoProcessRequest(HttpContext context, MediaRequest request, Media media)
{
 ...
  {
	if (Settings.Media.EnableRangeRetrievalRequest && Settings.Media.CachingEnabled)
	{
	  using (stream)
	  {
		this.SendMediaHeaders(media, context);
		new RangeRetrievalResponse(RangeRetrievalRequest.BuildRequest(context, media), stream).ExecuteRequest(context);
		return true;
	  }
	}
	else
	{
	  this.SendMediaHeaders(media, context);
	  this.SendStreamHeaders(stream, context);
	  using (stream)
	  {
		context.Response.AddHeader("Content-Length", stream.Stream.Length.ToString());
		WebUtil.TransmitStream(stream.Stream, context.Response, Settings.Media.StreamBufferSize);
	  }
	  return true;
	}
  }
}

Since the setting turns off byte chunking for ALL media requests, not just PDF files, you will need to verify if turning this off will affect your solution in other ways. The reason for enabling chunked downloads is allow the browser to start downloading dynamically generated files immediately without having to know the total size. For example, if you are serving streaming media from the Sitecore Media Library then this may cause you issues. In that case you could override the default media handler and check the file type:

if (Settings.Media.EnableRangeRetrievalRequest && Settings.Media.CachingEnabled
        && stream.Extension.ToLower() == "pdf")
{
  ...
}

If you are generating PDF files on the fly in other parts of your application then you may want to eliminate byte chunking too or put in place the fix mentioned in the linked article.

2 comments

  1. Pingback: Force Download and Prompt User to Save Media from the Sitecore Media Library | jammykam
  2. Dean · April 1, 2016

    Thank you so much for this article – just what I was looking for!

Leave a reply to Dean Cancel reply