Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 16 users
Status: Fixed
Owner:
User never visited
Closed: Oct 2009
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug
M-4

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
Chrome doesn't set Content-Type for file upload when the file extension is not recognized.
Reported by yangl...@gmail.com, Jan 22 2009 Back to list
Chrome Version       : 1.0.154.42
Other browsers tested:
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. Write a simple file upload form like this one:

<html>
<body>
<form method="post" action="file_upload" enctype="multipart/form-data">
  <input type="file" name="thefile">
  <input type="submit" value="submit">
</form>
</body>
</html>

2. Open the test page in chrome
3. choose a file with a weird extension. In my case the extension was 
".aes". Submit the form.
4. Use some tool to monitor the http request and you will notice that 
Content-Type is not set for thefile. (In my case I wrote a webwork-based 
web application as the server and dumped the request there.)

For the same test, Firefox 3 uses "application/octet-stream" as the Contet-
Type for the file and IE7 uses "application/x-zip-compressed"

5. Re-do the test with a well-known file extension, such as ".xml". Chrome 
properly detected the content type as "text/xml" and set the field in the 
request.

What is the expected result?

There should be a Content-Type assigned to the uploaded file. Even if the 
file extension is not recognized, a default value such as 
"application/octet-stream" might be good enough, like what Firefox does.

What happens instead?

The Content-Type field for the uploaded file is missing.



 
Comment 1 by abarth@chromium.org, Jan 22 2009
Labels: -Area-Misc Area-Compat
Status: Assigned


Comment 2 by Deleted ...@, Feb 21 2009
Yes and many internet services do not work on Chrome because they reject request if 
content type is not set for file. Google fail.
Comment 3 by jon@chromium.org, Jul 20 2009
Labels: -Area-Compat Area-BrowserBackend Mstone-4
Is there any estimate as to when that bug might be fixed? Thank you!
Comment 5 by Deleted ...@, Oct 13 2009
What's worse RFC 2388 says that without Content-Type specified, it defaults to
text/plain, which is definitely wrong.
Comment 6 by abarth@chromium.org, Oct 16 2009
Status: Upstream
This needs to be fixed in WebCore:

https://bugs.webkit.org/show_bug.cgi?id=30433
Comment 7 by abarth@chromium.org, Oct 16 2009
Status: Fixed
Fixenated: http://trac.webkit.org/changeset/49682
Great, thanks a lot. Any idea when a public version of Google Chrome will include
that fix? This issue is tagged 'Mstone-4' but I don't know how to translate that into
an actual product version? Will be helpful to track when we no longer need some
special workaround on our server (which takes RFC 2388 very seriously).
Comment 9 by abarth@chromium.org, Oct 17 2009
Yes.  The change should be on the 4.0 train.  That means it should be in all future versions labeled 4.0.  In 
particular, the fix should hit the Dev channel next week.
Labels: -Area-BrowserBackend Area-Internals
Comment 11 by guz...@gmail.com, Nov 2 2010
I just reproduced this bug on Chrome 7.0.517.41 when trying to upload the attached files. Note that the seq file is plain text, so I would expect to get "text/plain", and not "application/octet-stream". I get null for both.
eds.eds
2.1 MB Download
seq.seq
577 bytes View Download
Comment 12 by aun...@gmail.com, Nov 19 2010
The same appears to be appening on Chrome 9.0.576.0 dev, on windows server 2003, SP2
I get this on Chrome 7.0.517.44 and 8.0.552.215 when uploading a file with no extension. 

I get null as the content type. I'm using JakataMultipart request and ServletFileUpload in Struts 2 (2.0.14)

It works for the same file if I add an extension (e.g. ".bin") or if I use Firefox.
Comment 14 by r...@kde.org, Dec 14 2010
Also still experiencing this bug on 9.0.576.16 dev, osx
Comment 15 by Deleted ...@, Dec 21 2010
Chrome 8.0.552.224 give me the same bug uploading a .zip file the content type is null, on window 7 pro.
Comment 16 by Deleted ...@, Dec 22 2010
This fix doesn't appear to be working. Google Chrome doesn't set any value on Content-type. I'm using Google Chrome which version is 8.0.552.224 on Windows XP. 
confirming this bug is present in Chrome 8.0.552.231 on osx. Not sure if ChromeDev are watching comments on closed issues, so raised a new bug here: http://code.google.com/p/chromium/issues/detail?id=67876

Comment 18 Deleted
Comment 19 by Deleted ...@, Jan 24 2011
I can reproduce the bug with release : 8.0.552.237 (Build official 70801)
Is it really fixed or not yet?
See my headers with a zip file : 
<mimeHeaders>
 <content-type>text/plain</content-type>
 <content-transfer-encoding>base64</content-transfer-encoding>
 <content-disposition>form-data; name="EventZipFile"; filename="cargo_CustomerUpdateNotify-v02.zip"</content-disposition>
</mimeHeaders>
Comment 20 by Deleted ...@, Jan 24 2011
Sorry : fixed with release : 10.0.649.0 (Build de développement 72331)

I used Google Chrome 8.0.552.237

Regards
Comment 21 by Deleted ...@, May 13 2011
just got this bug back in version 11.0.696.65:

bad session (chrome)
_____________
POST /open/1 HTTP/1.1
User-Agent: Shockwave Flash
Host: n1.svms.mobi
Content-Length: 1
Connection: Keep-Alive
Cache-Control: no-cache

result:
.HTTP/1.1 400 Bad Request


good session (mozilla) for comparison 
_______________
POST /open/1 HTTP/1.1
Content-Type: application/x-fcs
User-Agent: Shockwave Flash
Host: n1.svms.mobi
Content-Length: 1
Connection: Keep-Alive
Cache-Control: no-cache

result:
.HTTP/1.1 200 OK


..looks like it is a kind of tradition to reproduce this issue again and again :) (joke) 
Could you please let us all know when it will be *permanently* fixed? 




Comment 22 Deleted
Comment 23 by Deleted ...@, May 13 2011
in addition to previous post: 
just tested 11.0.696.68 - same issue, no content-type in POST
same issue for 12.0.742.122 - no content-type
Project Member Comment 25 by bugdroid1@chromium.org, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 26 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Mstone-4 -Area-Internals M-4 Cr-Internals
Project Member Comment 27 by bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment