Copy link to clipboard
Copied
i don't use this application often, but it has worked previously within the last month. However now my cffile is ALWAYS translating mime type to "application/x-itunes-itlp" even though it is sometimes a pdf, sometimes a word doc, sometimes an excel file etc.
My <form> tag has enctype="multipart/form-data"
The error is being thrown on the following line of code:
<cffile action="upload" fileField="docUpload" destination="#dirPath#" nameConflict="overwrite" result="fileUpload" accept="application/vnd.ms-word, application/msword, application/vnd.ms-powerpoint, text/plain, application/x-pdf, application/pdf, application/vnd.wordperfect, application/vnd.ms-excel, application/zip, application/x-zip, application/x-zip-compressed, application/octet-stream, application/x-compress, application/x-compressed, multipart/x-zip">
and the error, no matter what file so far (except text files) is:
The MIME type of the uploaded file application/x-itunes-itlp was not accepted by the server.
My question: who decides what mime type a file has? is it the browser or the cffile tag? If it's the browser, which i'm starting to suspect, is it something i can change in my own browser? (I have both firefox 3.5.7 and IE 6) if it's the cffile tag, can i change how it behaves?
Copy link to clipboard
Copied
I can't explain the error, however the upload directory had been deleted by cvs. As soon as i put
that back the code no longer felt all my files were itunes itpls.
Note- this only worked locally. i did a chmod 777 on the production and staging directories machine and they're still telling me i'm upoading an itunes itlp file.
Copy link to clipboard
Copied
The client's browser determine the MIME type. On a Windows PC, at least for Internet Explorer, you can examine the MIME types associated with a file extension in the registry. Look at HKEY_CLASSES_ROOT > .xls and check the value of the "Content Type" key. Note I am using .xls as an example, this applies to any file extension.
Since the browser specifies the MIME type for a form post it could be inaccurate. I would verify the file extension and do a virus scan of all uploaded files on the server side rather than depending on the accept attribute of CFFILE.
Copy link to clipboard
Copied
well, my registry has the correct content type for .xls, .doc and .pdf so that isn't the problem.
i use accept but i also check the file extension after the file is uploaded...not sure how to virus check a file being uploaded...i'll hunt up some cf blogs to see examples.
my real problem is that i really need that mime type to be correct as i use it at output as well. Is there any option OTHER than modifying the mime type in the structure after it's uploaded to convince the system these aren't itunes-itpl files?
Copy link to clipboard
Copied
Have you tried this from another PC to isolate whether it's the configuration of your PC?
You can see the MIME types of HTTP requests using an HTTP sniffer like the Firefox plug-in "Live HTTP Headers", or Charles, or something. That shows you the raw HTTP transmission, which is handy for investigating situations like this.
There is also the chance your web server is reporting the MIME type wrong to CF. It is, after all, the web server passing the file to CF, not the client browser.
Possibly test the upload using the inbuilt JWS web server to see what happens using that.
--
Adam
Copy link to clipboard
Copied
OK. So i never found a good solution, although Adam's suggestions help find the problem, the solution may not be within my means, what i did find out was that every file uploaded from this machine (and this machine only) to any server running my code is being identified at some point as an itunes/ipl file. I'll be glad to find out where the problem was as i checked this computer's registry and it appeared to be correct, but didn't know how to see whether it was the browser or the server after that.
I removed "accept" from the call and then ran the following code (which modifies the structure created by cf, see my note above) if the file extension matched my pre-arranged set of file extensions and threw an error if it did not (I did this is because i'm actually storing the mime type for when i output it, not because a filter that rejects by file extension didn't work for me)
NOTE: macintosh and unix users may encounter issues because of this code on files without extensions. But they would have trouble with most measures as they are all based on file extension and thankfully, all of my admin users uploading documents are inside my firewall and i know they have windows pcs.
Code: (note fileUpload is the variable created by cffile)
<cfif fileUpload.clientFileExt eq "doc" and fileUpload.CONTENTSUBTYPE NEQ "msword">
<cfset fileUpload.CONTENTSUBTYPE = "msword">
<cfif fileUpload.contenttype neq "application">
<cfset fileUpload.contenttype = "application">
</cfif>
</cfif>
<cfif fileUpload.clientFileExt eq "ppt" and fileUpload.CONTENTSUBTYPE NEQ "vnd.ms-powerpoint">
<cfset fileUpload.CONTENTSUBTYPE = "vnd.ms-powerpoint">
<cfif fileupload.contenttype neq "application">
<cfset fileUpload.contenttype = "application">
</cfif>
</cfif>
<cfif fileUpload.clientFileExt eq "txt" and fileUpload.CONTENTSUBTYPE NEQ "plain">
<cfset fileUpload.CONTENTSUBTYPE = "plain">
<cfif fileupload.contenttype neq "text">
<cfset fileUpload.contenttype = "text">
</cfif>
</cfif>
<cfif fileUpload.clientFileExt eq "pdf" and fileUpload.CONTENTSUBTYPE NEQ "pdf">
<cfset fileUpload.CONTENTSUBTYPE = "pdf">
<cfif fileupload.contenttype neq "application">
<cfset fileUpload.contenttype = "application">
</cfif>
</cfif>
<cfif fileUpload.clientFileExt eq "wpd" and fileUpload.CONTENTSUBTYPE NEQ "wordperfect">
<cfset fileUpload.CONTENTSUBTYPE = "wordperfect">
<cfif fileupload.contenttype neq "application">
<cfset fileUpload.contenttype = "application">
</cfif>
</cfif>
<cfif fileUpload.clientFileExt eq "xls" and fileUpload.CONTENTSUBTYPE NEQ "vnd.ms-excel">
<cfset fileUpload.CONTENTSUBTYPE = "vnd.ms-excel">
<cfif fileupload.contenttype neq "application">
<cfset fileUpload.contenttype = "application">
</cfif>
</cfif>
<cfif fileUpload.clientFileExt eq "zip" and fileUpload.CONTENTSUBTYPE NEQ "zip">
<cfset fileUpload.CONTENTSUBTYPE = "zip">
<cfif fileupload.contenttype neq "application">
<cfset fileUpload.contenttype = "application">
</cfif>
</cfif>
<cfif fileUpload.contentsubtype eq "x-itunes-itlp">
<cfset fileupload.contentsubtype = "octet-stream">
</cfif>
The final if is effectively a catch all for this specific problem which was that it was returning "application/x-itunes-itlp", and so if going through all that stuff on code with the proper file extensions doesn't work, then there's a bug in this code, it is, however, not the best way to handle it, and i hope to have time next week to follow Adam's advice and follow up WHERE the type is being modified.
Adam, can you point to a resource explaining how to use JWS to upload files? I'm still new to the java underbelly.
Copy link to clipboard
Copied
CF runs atop of JRun, which has its own web server.
I'm pretty sure by default it listens on port 8500 or 8300, so you could simply try: http://your.host.here:8500/path/to/file.cfm and that might be it. Other than that you'll need to look in your CF instance's jrun.xml file. On a multi-server CF install, this is in [JRun dir]/servers/[instance name]/server-inf/jrun.xml, and do a search on "This is the built-in JRun Web Server", and just below that there's a node for the port the JWS is listening on, eg: <attribute name="port">8300</attribute>
I am not sure of the location of this file on a stand-alone CF install, I'm afraid. I never use a stand-alone install, so don't have one to refer to (and I never remember these file locations, I need to check 😉
If your IIS website has required virtual directories configured, you'll need to set those up in the instance's jrun-web.xml, which is in the WEB-INF dir ( [JRun dir]/servers/[instance name]/cfusion-ear/cfusion-war/WEB-INF on multi-server, cfusion/WEB-INF - I think - on stand-alone). There's an example within the file of how to set up a mapping.
--
Adam
Copy link to clipboard
Copied
I ended up taking BKBK's suggestion of removing the accept attribute.
It did turn out to be some configuration issue on one PC, but I'm not aware of any recent itunes changes.
Copy link to clipboard
Copied
I have an idea for a test. Leave out the accept attribute, and see what Coldfusion does with just:
<cffile action="upload" fileField="docUpload" destination="#dirPath#" nameConflict="overwrite" result="fileUpload">
Copy link to clipboard
Copied
I just encountered this problem myself. Did you ever find a solution?
Get ready! An upgraded Adobe Community experience is coming in January.
Learn more