|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 : 18.104.22.168 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.
Jan 22 2009,
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.
Jul 20 2009,
Oct 9 2009,
Is there any estimate as to when that bug might be fixed? Thank you!
Oct 13 2009,
What's worse RFC 2388 says that without Content-Type specified, it defaults to text/plain, which is definitely wrong.
Oct 16 2009,
This needs to be fixed in WebCore: https://bugs.webkit.org/show_bug.cgi?id=30433
Oct 16 2009,
Oct 17 2009,
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).
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.
Dec 18 2009,
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.
Nov 19 2010,
The same appears to be appening on Chrome 9.0.576.0 dev, on windows server 2003, SP2
Dec 2 2010,
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.
Dec 14 2010,
Also still experiencing this bug on 9.0.576.16 dev, osx
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.
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.
Dec 23 2010,
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
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>
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
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?
May 13 2011,
in addition to previous post: just tested 11.0.696.68 - same issue, no content-type in POST
Jul 28 2011,
same issue for 12.0.742.122 - no content-type
Oct 13 2012,
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.
Mar 10 2013,
Mar 13 2013,
|► Sign in to add a comment|