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

Issue metadata

Status: Fixed
User never visited
Closed: Oct 2009
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • 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, Jan 22 2009 Back to list

Issue description

Chrome Version       :
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:

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

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 

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, 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, 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, Oct 16 2009

Status: Upstream
This needs to be fixed in WebCore:

Comment 7 by, Oct 16 2009

Status: Fixed
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, 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, 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.
2.1 MB Download
577 bytes View Download

Comment 12 by, 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, 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:

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 : 
 <content-disposition>form-data; name="EventZipFile"; filename=""</content-disposition>

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


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
Content-Length: 1
Connection: Keep-Alive
Cache-Control: no-cache

.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
Content-Length: 1
Connection: Keep-Alive
Cache-Control: no-cache

.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, 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, Mar 10 2013

Labels: -Mstone-4 -Area-Internals M-4 Cr-Internals
Project Member

Comment 27 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment