Error on form submission containing file input

The error "Corrupt form data: premature ending" appears in the cfserver.log when a form is submitted with a file (to be uploaded to the server) from a form using ENCTYPE="multipart/form-data" and the error occurs while using https and ONLY in IE.  Firefox, Safari, etc. are not experiencing the problem.  The user experiences either an immediate "500 Internal Server Error" response or a long lag before receiving the 500 error.

I've seen numerous posts about this issue in the Macromedia forums (via Google groups), but little on the cause or the solution.  There was one very informative post about changing some IIS settings, but we are running Red Hat Linux and ColdFusion MX 7 (with up to date hotfixes).  Perhaps someone out there has run into this problem or has a resource they can point me to.

 Thanks in advance.

 - Louis
Who is Participating?
I agree with Jeff and completely disagree with Rob.  Not only is it not a solution to tell your users not to use IE - good or bad you simply can't tell ~85% of your potential market that their doing something wrong in order to access your site (Source:!  You have to find a solution, which in this case is very difficult.

The problem is fairly well known issue with JRun (which of course affects CF7 since it's a JRun application) and even a few of the other J2EE variants.  Jeff is correct in that it's usually due to special characters outside normal ASCII ranges.  Is it possible to transform the field that's containing these characters to something else?  At a guess, unless you only have one or two special chars which are known this could be problematic (if they are always the same you could use a pre-submission validation routine to substitute a character or series of characters to indicate replacements and then reverse the conversion once the data has reached the server.

A better (although hugely in-elegant solution) might be to split your form that does the upload into two parts - like a wizard.  Form_1 would contain all the form fields with the exception of the file for upload and could then submit with a enctype of "application/x-www-form-urlencoded" which should eliminate the error on the ASCII, and then on the action page which processes that form submission, place your file input and have the upload go by itself as a enctype "multipart/form-data" which should also work correctly.

To make it at least as good a work-around as possible you could use a script to determine what browser the user is currently using to view/submit the form and only switch to the 2-part process if they are using IE.  That way everything works for everyone, but only the IE people have to go through the 2-step process.

Sorry I can't be of more help, but far smarter people than I have run up against this problem, and (to my knowledge at least) haven't found a good solution yet.

not really a solution but........suggest that your users use a stable browser, as in not IE
IE is every bit as stable as any other browser, moreso in some cases.

It would seem, from my experience, to be an issue with high ascii data in other fields in a form that's set to multipart/form-data.
kidding..... jeez
I have a behavior, which is IE-only, that "cleanses" form field data by converting high-ascii characters to their html character entities.  That seems to eliminate the problem.  It does require the scripting is enabled, so a small percentage will still experience a problem.  Due to work restrictions, I'm not permitted to post the code for free, unfortunately,
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.