Bug 20668 - multipart/form-data does not always include Content-type for submitted files
Summary: multipart/form-data does not always include Content-type for submitted files
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 525.x (Safari 3.1)
Hardware: All All
: P2 Normal
Assignee: Alexey Proskuryakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-05 09:58 PDT by Tim Burt
Modified: 2008-09-08 09:23 PDT (History)
1 user (show)

See Also:


Attachments
test case (a CGI for Apache) (402 bytes, text/plain)
2008-09-08 07:54 PDT, Alexey Proskuryakov
no flags Details
proposed fix (1.79 KB, patch)
2008-09-08 08:03 PDT, Alexey Proskuryakov
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Burt 2008-09-05 09:58:18 PDT
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.
Comment 1 Tim Burt 2008-09-05 10:06:06 PDT
(In reply to comment #0)
> ... application/octec-stream ...
should read application/octet-stream
Comment 2 Alexey Proskuryakov 2008-09-08 04:53:07 PDT
Are there any examples of such applications on he Web to test with? Would it be possible for you to make a test case?
Comment 3 Tim Burt 2008-09-08 06:46:08 PDT
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).
Comment 4 Alexey Proskuryakov 2008-09-08 07:54:13 PDT
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.
Comment 5 Alexey Proskuryakov 2008-09-08 08:03:51 PDT
Created attachment 23261 [details]
proposed fix
Comment 6 Darin Adler 2008-09-08 08:29:19 PDT
Comment on attachment 23261 [details]
proposed fix

r=me

I wish there was a cleaner idiom for "not empty".
Comment 7 Alexey Proskuryakov 2008-09-08 09:23:53 PDT
Committed in <http://trac.webkit.org/changeset/36269>.