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 4 users

Issue metadata

Status: WontFix
Closed: Jul 2015
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression

Sign in to add a comment

Uploading .zip files sets application/octet-stream as mimetype.

Reported by, Jul 5 2013

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36

Steps to reproduce the problem:
1. Create a simple fileupload form.
2. Upload attached zip file (created with winrar)
3. Check content-type of the upload.

What is the expected behavior?
Content-type application/zip, application/x-zip or application/x-zip-compressed

What went wrong?
content-type is set as application/octet-stream which means that forms which filter on mimetype will break.

Did this work before? Yes Not really sure, probably before the changes which led to

Chrome version: 28.0.1500.71  Channel: beta
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 11.7 r700

Is there a way to revert to an older version of chrome and test this out?

The release channel version 27 also displays this incorrect behaviour.
Forgot attachment
3.1 KB Download

Comment 2 by, Jul 9 2013

Labels: Cr-Internals-Network-HTTP Cr-Blink-Forms
Labels: Needs-Feedback
Could you please code for file upload form or any URL to upload and check. Please provide more steps or screen-cast of the issue will help in triage further. 
Sorry for the late response.

See the attached files for a simple form upload which checks the content-type client side. Screenshots of the response on the current chrome beta (29.0.1547.22 beta-m) and FF release (22.0)

115 KB View Download
437 bytes View Download
71.9 KB View Download
Hmmm, these are of course client side and dependent upon the File api. I can't seem to find a simple 'echo filetype' server side script.

I have attached two screenshot of the developers toolbar on our production system (written with wicket). Unfortunately, I can't disclose the source code.
162 KB View Download
206 KB View Download

Comment 6 by, Apr 25 2014

Labels: Cr-Blink-Forms-Submission
Have the same problem in Version 35.0.1916.153 m.
Our upload form works just fine in IE10/11, but not in Chrome.

It reports application/octet-stream in Chrome and not application/x-zip-compressed.
thomas.ervik,Can you Please send me any sample URL where we can perform File upload to repro the above issue?Mean while can you confirm this issue on Latest canary :38.0.2076.0 (Official Build 280546) as well.

Also please send me the screen shot for the above issue.

Comment 9 by, Dec 16 2014

I can confirm this bug. Also the bug is only affecting the Windows version of Chrome. Tested using  Version 39.0.2171.95 on windows and it has this issue, while on linux machine it works fine.
Labels: -Needs-Feedback

Comment 11 by Deleted ...@, May 18 2015

Chrome build: 42.0.2311.152 m on windows. After I added application/octet-stream upload works.
Labels: Needs-Feedback
With Chrome 43 stable and Windows 7, fileuploadtest.html in #4 showed application/x-zip-compressed.

Is this reproducible now?

It works for us now, apparently since Chrome version 34 and I just confirmed it works in Version 45.0.2446.0 canary (64-bit) (both on windows 7).

But the other commenters above have had problems in versions inbetween so I don't think this issue can't be resolved unless the problem has been solved for them as well.
Labels: -Needs-Feedback
Status: WontFix
Please add comments if anyone still has the issue.

Components: Internals>Network
Components: -Internals>Network>HTTP

Sign in to add a comment