of the CFHeader tag - neither one made a difference in the behaviour.
I read through the RFC, and this appears to apply more to email than to web
pages. However, I made sure I understood the concepts involved.
The thing is that we have similar code in production that works fine. In
this particular case, our binary files get dumped to the web page as raw
text. I can change this behaviour a little to a point where we ARE prompted
to save, but then the filename we're prompted with is for the action page,
not the one set in the CFHeader tag, and when we do agree to open/save the
file, nothing happens (the saving dialog just opens and no data get's
transferred). This is repeatable with PDF and DOC files. However, for some
reason JPG and GIFs work fine.
Thanks again for the reply, but I'm still looking for a solution (digging on
my side, as well as hoping someone on the list might be able to help out).
Shawn
-----Original Message-----
From: Mosh Teitelbaum [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2003 1:12 PM
To: CF-Talk
Subject: RE: CFContent and PDF problems
Shawn:
Your CFHEADER is missing a value. The VALUE for the Content-Disposition
header should begin with either "inline;" or "attachment;" as in:
<CFHEADER NAME="Content-Disposition"
VALUE="inline; filename=#oFTS.OriginalName#">
See RFC1806 ( http://www.faqs.org/rfcs/rfc1806.html
<http://www.faqs.org/rfcs/rfc1806.html> ) for more details.
--
Mosh Teitelbaum
evoch, LLC
Tel: (301) 942-5378
Fax: (301) 933-3651
Email: [EMAIL PROTECTED]
WWW: http://www.evoch.com/ <http://www.evoch.com/>
-----Original Message-----
From: Shawn Grover [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2003 12:52 PM
To: CF-Talk
Subject: CFContent and PDF problems
We're using a CFContent to push files to a client page (after they've
clicked on an appropriate link of course). Things are working for image
files, but we are getting odd behaviour when we try to view PDF documents.
Here's the code in question:
<!--- Set the name of the download file in the HTTP header --->
<CFHEADER NAME="Content-Disposition" VALUE="filename=#oFTS.OriginalName#">
<!--- Send the file (using the physical path to it) --->
<cfcontent type="#sMimeType#" file="#sSourcePath#" deletefile="no">
and the supporting variables are:
Mime TYpe: application/pdf
File Name: 2003100809073301noisereport.pdf
Path and File:
C:\inetpub\wwwroot\caa\ctreg_web\fts_files\2003100809073301noisereport.pdf
What's happening is that the PDF file is getting dumped as raw text to the
page, or we see a prompt to save our action page (getfile.cfm). However,
this is a near exact copy of an existing routine from another application we
did. In the other application, the PDF plug-in kicks in and we view the
file in Adobe Acrobat. It would appear that in the process of copying and
modifying the code, something minor was changed to result in this new
behaviour. However, we've now had 3 people look at the code and we don't
see anyting that should be causing this issue.
Does anyone see anything wrong or have any suggestions? My thoughts are
that we have missed something stupid...
Thanks in advance.
Shawn
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
