This was observed using Safari on Mac OS X 10.4 and Windows XP, and Google Chrome on Windows XP, so it is believed to be common to all platforms. The fundamental problem is that the Content-type for a file submitted using input type=file is not set if the file type (extension?) is not "recognized" (sorry, but I don't know what determines exactly when it will be set and when it will not). For example, submitting an Excel (*.xls) file from a client that does not have Excel installed results in the file data being sent with no Content-type specified. Other browsers set the Content-type to application/octec-stream in this case, and my interpretation of the spec implies that is the correct behavior. One serious implication of this flaw is that the Struts2 FileUploadInterceptor expects the Content-type to be set for each uploaded file, and when it is missing, the interceptor emits an error and fails to set any of the parameters that are later expected/used by the Struts2 action class to process the file(s). The net result is that users using applications built on Struts2 are not able to upload files using webkit-based browsers.
(In reply to comment #0) > ... application/octec-stream ... should read application/octet-stream
Are there any examples of such applications on he Web to test with? Would it be possible for you to make a test case?
I'm sorry, but the application I'm working with now is not exposed externally, and I don't have a framework to test webkit. I was hoping webkit contained some existing tests for multipart/form-data inputs that could be extended to test this situation (i.e. send a file of "unknown" content-type to confirm that Content-type: application/octet-stream is not sent for that file).
Created attachment 23259 [details] test case (a CGI for Apache) Unfortunately, I don't think that we have any infrastructure for testing file uploads yet. I made a custom test, and can confirm the issue.
Created attachment 23261 [details] proposed fix
Comment on attachment 23261 [details] proposed fix r=me I wish there was a cleaner idiom for "not empty".
Committed in <http://trac.webkit.org/changeset/36269>.