New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 139105 link

Starred by 13 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Sign in to add a comment

incorrect mime-type for csv-files

Reported by, Jul 26 2012

Issue description

Chrome Version       : 20.0.1132.57 (Offizieller Build 145807) m
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Other browsers tested:
  Firefox 14.x: OK

What steps will reproduce the problem?
1. create a website containing a <input type="file" id="uploadFile" name="uploadFile" size="50">
2. upload a csv-file and check the mime-type of that file

What is the expected result?
Chrome sends "application/" as mime-type

What happens instead?
Chrome should send either "text/csv" or "text/comma-seperated-value" as mime-type

Please provide any additional information below. Attach a screenshot if


Comment 1 by, Jul 26 2012

Labels: -Area-Undefined Area-Internals Internals-Network
Labeling this a network bug, in the hopes that someone more familiar with where upload mime types come from (WebKit?  The Windows registry?  Format sniffing in net/?) can better triage this bug.

Comment 3 by Deleted ...@, Jul 30 2012

Incorrect mime-type for csv-files when downloading a dynamically created csv file:
There is another issue happened when I download a dynamically created csv file. The file name is always set as "export" (which is the path name), but not the "list.csv" in the response headers.

Is that a bug associated with this issue?

Response Headers:
Content-Disposition:: attachment; filename=list.csv;
I don't think so. In my case its about uploading files and the mime-type which chrome sends to the server is incorrect

Comment 5 by, Jul 30 2012

minzhiR:  You have two colons after Content-Disposition.  Per spec (, I believe there also shouldn't be an extra semi-colon at the end of the line, though I assume we do handle that case.

Comment 6 by, Jul 30 2012

As mentioned in Comment #5, the Content-Disposition is malformed due to the extra : character.  There's an effort to harmonize the error handling behavior of all the browsers, and we've implemented the latest version of the spec.

Thanks for reporting the issue.  Ideally, we'd like all browsers to implement the spec, so we're likely to wait a bit before changing our behavior here to see if this issue occurs on more web sites.  If you notice this issue on other sites as well, please add a comment to this bug so that we can make an informed decision about whether to change our behavior.

Thanks again.

Comment 7 by Deleted ...@, Jul 31 2012

To mmenke:
Thanks for your comment, I missed the extra colon by an oversight. That download works well in IE and Firefox with the extra colon, so I thought it was a bug. That is my  mistake.
Thank you again.

Project Member

Comment 8 by, Mar 10 2013

Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network
I can confirm that Chrome (34, Windows 8 x64) still sends the wrong mime type. The RFC ( specifies text/csv but Chrome sends application/ instead.

Comment 10 by Deleted ...@, Nov 29 2014

I am having this issue, but it appears to be the same in firefox. This may be a window issue and not a chrome issue?
Status: Assigned
FWIW, Chrome 41 still sends application/
chrome 41.png
15.9 KB View Download
Did anyone found a resolution to this? I am having the same issue.

Comment 14 by, Jul 6 2015

It is possible to work around this by editing [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.csv\Content Type] and changing it to text/csv
Thanks cgrady! Sounds like Chrome is pulling the mime type from the registry.

cgrady and others who are encountering this issue, what mime types do IE and Firefox send in this case?

Comment 16 by Deleted ...@, Aug 11 2015

IE, Firefox and Chrome all upload as Content-Type: application/
Update to this, Firefox 50.0.2 reports the file as text/csv, which is correct. Edge and Chrome 54.0.2840.99 report as application/, which should only be used for .xls or similar files as far as I am aware.
Owner: ----
Status: Untriaged (was: Assigned)
Presumably, to "fix" this, we'd just add CSV as a primary MIME mapping to the list in; this list is consulted *before* looking at the file extension list in the Windows registry. Doing so would impact the MIME type if sniffing got involved in other codepaths (e.g. file download).

Having said that, I'm unconvinced that this is something we really need to do. On Windows 10 without Office installed (such that the CSV extension does not have a Content-Type specified in the registry), Chrome, Edge, Firefox and IE all upload with the type application/octet-stream.

Resetting triage flag, as I don't think the current owner has any plans of moving this forward.
Status: Available (was: Untriaged)
I'm going to shift this to "Available" to get it off the net bug triager's radar--it sounds like the problem is understood but isn't currently high priority to fix.

I can confirm that is right. Without MS Office installed al is OK and with "text/csv" becomes "application/"

would be nice to get some workaround to overcome that.. and somehow report this issue to MS..
 Issue 862565  has been merged into this issue.
Components: -Internals

Sign in to add a comment