cfcontent: I See Everything Twice!

At work, I keep getting requests that force me to use cfcontent, a la "We need to have this directory of PDFs out there that is not URL-addressable but that's available to a set of users who have Acrobat 4-6 on Windows 95-XP." I haven't yet been able to get cfcontent to oblige this request.

Assuming a query object qDocument that has everything about the document, the code I'm using to stream the PDF file to the browser inline is:

<cfheader name="Content-Disposition" value="inline; filename=#qDocument.sFilename#">
<cfcontent type="application/pdf" file="#request.stcGlobal.sSecureDir#\#qDocument.sFilename#">

Immediately above this block of code, I make a call to an Auditor CFC to audit that the user viewed the document:

<cfset iAuditId = application.objAuditor.insertAudit(sEmpId=session.objUser.getEmpId(), iDocumentId=qDocument.iDocumentId, sAuditAction="VIEW", sAuditDetail="Document """ & qDocument.sTitle & """ viewed by " & session.objUser.getFirstName() & " " & session.objUser.getLastName() & ".")> <!--- Audit document access --->

All well and good, right? Well, the Acrobat 6.0 client causes the request to occur twice, as I am getting the audit record with identical timestamps inserted to the database. Any other non-output producing code (such as a cfmail call) also executes twice. If the audit code is moved beneath the cfcontent call, it doesn't execute at all.

The Acrobat 4.0 client only inserts one audit record, but the file isn't served. Instead, a nice blank screen displays for the user.

This is one of those situations where I'm confident that the code itself is ok, and that the variance is occurring as a result of the client. Unfortunately, that doesn't really help me solve it. Life goes on.

---

UPDATE: The ColdFusion logs indicate that the Adobe Reader client is indeed making the request twice. On the first request, an HTTP Referer CGI variable is present, but on the second, it is not. Since this application is protected and wouldn't allow bookmarks or typing the path to the file serving script, checking for the presence of the CGI HTTP Referer is an accepteable solution and prevents the double audit problem. Progress.