[Looking for Charlie's main web site?]

CFMythbusters: For a file to be uploaded to CF, the page needs a CFFILE Upload tag, right? Wrong!

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
I was sharing some thoughts on a discussion list and figured others may appreciate the observation.

Have you ever assumed that for a file to be uploaded to CF, in a post to a CFM page, that that page needs a CFFILE Action="upload" in order to "receive" the file? It does NOT. Now, I'm being a bit technical here, but to be clear, the uploaded file will be "received" by CF, if posted to ANY CFM page whether that tag is there or not to "receive it". The point is that this uploaded file will be put in a temp directory, with a temp file name and extension, at least until the end of the request.

What the CFFILE Action="upload" does is just move the uploaded file from a temp directory to your named DESTINATION (as well as validate its type, report the file name, protect against or allow overwrites, and more, if you use the attributes on the tag for those features).

And if you do NOT process it, then that temp file will be removed at the end of the request (unless perhaps the request terminates unexpectedly).

Need proof? Want to learn more? Read on.

Just do an form file upload to a CFM page that has no CFFILE Action="upload". The file will still be uploaded, to a temp directory (from which CFFILE *would* move it). There's a trick to "seeing this", though. Again, the temp file (literally with a .tmp extension) will be removed when the upload page processing is done. You will need to pause the request long enough to be able to look in the directory (such as with Windows explorer) to see the file as uploaded. Fortunately, that pause is easily done.

Here's a template that demonstrates it all (see the comments/explanation that would appear onscreen):

<form method="post" enctype="multipart/form-data">
   <input type="File" name="test"><br>
   <input type="Submit"><br>
</form>
File will be uploaded to this directory: <br>
<cfoutput>#gettempdirectory()#</cfoutput>

<cfif request_method is "post">
<cfscript>
thread = createObject("java", "java.lang.Thread");
thread.sleep(javaCast("long", 5000));
</cfscript>
</cfif>

Notice that there is is no CFFORM tag in that code above. Its just a CF page that will "receive" a file upload.

(The call to the gettempdirectory function above is placed in a textarea, having nothing to do with the form above it, just to make it easy for you to copy/paste the path to look at it.)

On first loading the page above, open that temp directory with Windows Explorer or its equivalent, and then run the upload, pointing at some file of your own. Then refresh the directory display to see the .tmp file that was uploaded. This CFM upload page has been set to pause for 5 seconds after the upload. The tmp file will disappear when the form submission page process has completed.

So what's really doing the "upload"?

So what's actually doing the upload? I would assume the web server.

Why is it going into a CF temp directory? I assume it's because the web server connector causes the web server to tell CF to do so. It might be useful to try to do an upload to a plain HTM extension file, but you need a means to cause the page to pause to see if the file was uploaded (to an OS-specific temp directory, I'd guess). (FWIW, I tried uploading large files to the CF page and just couldn't see them being uploaded to the temp directory without doing the pause.)

So lesson learned: don't assume that only a page with a CFFILE action="upload" can "receive" an uploaded file. In fact, any CF page can "receive" an uploaded file. This may seem rife for abuse, and indeed CF has for several releases had some settings in the CF Admin (in the first, main Settings page) to put some reasonable throttles on file uploads.

And remember, too, that the temp file is supposed to be deleted at the end of the request. I suppose if something caused the page to never finish (or never finish properly), you could end up with files stored in the temp directory which would never be removed.

But then, they are just .tmp files, so it would be hard for them to be used in any nefarious way.

Hope this helps someone.

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Comments
Charlie,

I had learned from my first efforts with CFFile that it doesn't actually upload the file, it just transfers it from the server's temp directory to the specified directory, or to the application's memory. From what I understand, the file form field just gives a path to the uploaded file in the temp directory.

That said, even though CFFile may not be working as advertised, there are still ways you can upload the file and process the uploaded file using the java.io.String and FileReader classes. Samuel Neff gives a very nice discussion on how to do this on his blog:

http://www.rewindlif...

Of course this assumes that your shared hosting account allows you to use createObject and java in general.

See you at CFUnited.

larry
Larry, thanks, but I wasn't asserting that it wasn't working. I was just explaining, for those who have thought CFFILE did the uploading, that it does not: that (as you say) all it does is the move on the server from temp to intended destination. I was just pointing this out for those who have wondered or want, in the future, a place to point those who would argue otherwise. See you at the conference.
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting