Bulletproofing downloads of large PDFs against browser misconfiguration?

Question

I have a site running apache whose main purpose in life is to serve up large (10-30 Mb) pdf files. I get emails fairly frequently from users saying that they're having problems downloading the files:

• "will start to download, but the download doesn't complete, it freezes at about 25%."

• "It seems to find the page, but just spins and spins ... I let it go 5 min. No data. HOWEVER: When I chose "download" I got it in seconds."

• "It somehow starts loading the pdf at around 10%, both in Chrome and Firefox."

Since I can't reproduce the problems, and they don't seem to occur for the vast majority of users, it's very hard to figure out what's up. Presumably the users have misconfigured their browsers or plugins somehow, or maybe in some cases it's a usability issue with their browser or plugin. Getting users to report specific error messages or behavior, describe their configuration, etc., is like pulling teeth.

I've seen some other questions that describe similar problems, but they seem specific to IIS, whereas I'm running apache:

• Acrobat 7 stalls downloading PDF from IIS 7

• PDF download hanging from server with Firefox/Chrome

This bug doesn't seem to match the (vague) reports I've gotten:

• 'IE cannot display the webpage' when opening PDFs

Are there any techniques for bulletproofing my setup so that users don't experience so many of these problems? Browser detection in javascript with an appropriate message? Warning users against particular browser/plugin combinations, or automatically detecting those combinations? Right now, I can't even tell which lines to look at in my apache log file to see whether any error is recorded on the server side. Possibly all of this becomes more complicated than you'd expect for serving up a plain old static file, because Adobe Reader tries to be tricky -- although these PDFs are not optimized.

If anyone would like to try to reproduce the error, a pdf for which users have reported problems is here: http://www.lightandmatter.com/sr/sr.pdf [It may now be impossible to reproduce the behavior because I've implemented Håkan Lindqvist's answer.]

Answer 1

To figure out if there is anything you can do to improve this I think you will really want to find out what browser / pdf viewer plugin combination(s) this problem occurs with and try to find a way of reproducing it.

Chrome and Firefox are mentioned in the question but at least Chrome comes with its own pdf viewer. However, it's entirely possible to use the Acrobat Reader plugin or similar with either of these browsers so just knowing the browser doesn't really answer what software was used.

On the other hand, if the goal is to have users simply download the files and you do not want to deal the oddities of various plugins you may want to consider instructing the browser not to open the file but just download it.

This would be done by setting Content-Disposition: attachment in the HTTP response.

Of course, depending on how your users are used to work with these files this could also cause confusion but I imagine just having your browser save a file and then opening it locally should be less prone to error.

Answer 2

If you can replicate this, take a look at the download status, request and response headers, it will give you a clue.

**Response Headers**
Accept-Ranges   bytes
Connection  Keep-Alive
Content-Length  9531692
Content-Range   bytes 11278-9542969/9542970
Content-Type    application/pdf
Date    Tue, 24 Jun 2014 21:08:45 GMT
Etag    "1b78005-919d3a-4f550c11dff40"
Keep-Alive  timeout=15, max=100
Last-Modified   Mon, 24 Mar 2014 02:11:33 GMT
Server  Apache/2.2.16 (Debian)


**Request Headers**
Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Connection  keep-alive
Host    www.lightandmatter.com
If-Range    "1b78005-919d3a-4f550c11dff40"
Range   bytes=11278-
User-Agent  Mozilla/5.0 (Windows NT 6.2; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0

Download Status - 206 Partial Content. By definition, this means the "Client" made this request, not the other way around.

So the client is requesting, in this case bytes=11278- , the response headers confirms that it is receiving the Accept-Ranges.

There is one thing that does confuse me, is that there is a hypen after the digit 8.

Originally posted here, but a possible (untested) solution is to add the following to the htaccess file.

# Disable Byte-range for PDF files
<Files *.pdf>
    Header set Accept-Ranges none 
</Files>