We've recently added security to our file downloads by configuring the web server (Apache) to allow downloads only when the "referer" string (one of the HTTP headers) matches our server. All non-PDF files download fine (i.e., we can download MS Office documents, text documents, etc.) in all target browsers (Firefox, Safari, IE) under this new configuration. And PDF files also work fine so long as the browser is configured to simply download the file rather than open it via the Adobe Reader plugin.
But attempting to open PDF in the browser directly (i.e., via the plugin) fails consistently: The first page of the file displays in the browser, and then the download hangs. The server simultaneously records an "access denied" (403) error. Does anyone know how come?
My only theory so far is that the plugin is attempting to fetch the file at least once after the initial download begins. The server would presumably deny this request (since the referer string wouldn't match our server), and the download would hang at this point.
Is this theory right? Or does anyone have a different theory?
Assuming we don't want to change the way we're doing security on the server, how can we work around this problem?
FWIW, that's not really security as the headers can easily be manipulated. You might want to check the server logs to see what the referrer is, and you could then add whatever it is to the server configuration. But check different versions of Acrobat/Reader to make sure it's consistent. Also, consider what should happen if the user has a non-Adobe PDF viewer.
Regarding non-Adobe PDF viewers: They seem to work fine. My instance of Safari, for example, which is configured to open PDF inside the browser without using the Adobe plugin, works without a hitch. This is one more piece of evidence suggesting that the source of the problem lies in the Adobe plugin itself.