0

I thought I'd repost this since I have more detailed information:

THE ISSUE: Android Chrome browser renames a file to "Download" in all cases. It renames the type to ".bin" in some instances (if the extension is .MOV, for instance). As I've mentioned before, the Firefox and Dolphin browser apps on the same Android device don't exhibit this behavior. The files are downloaded correctly. As a side note, I already tried specifying a "Download" attribute within the Anchor element with no luck. The "Download" attribute gets ignored even by the Android Chrome browser in this case. My hunch is that it's because of the way we're streaming the file that the "download" attribute is being ignored. Another thing to note is that the desktop version of the Chrome browser downloads files without the issue (no renaming). I think there's some security feature built into the Chrome browser that is causing these renaming probs.

BACKGROUND INFO: The web server is IIS 7.5 on a Windows Azure cloud. The web application in use is Microsoft's MVC framework for routing. So when a file is selected to download from the Chrome browser within an Android device, a download method on the server is accessed using MS MVC routing. Within this method, we're specifying the header information and streaming chopped up pieces of the file using httpResponse. This works beautifully for any other browser app on the Android device (Firefox and Dolphin, for instance) and is able to save with the correct file name and type. With Chrome, however, the file and type (sometimes) gets renamed.

Here are the response headers when I download a .MOV file:

*HTTP/1.1 200 OK Cache-Control: private, s-maxage=0 Content-Length: 54295903 Content-Type: application/octet-stream Server: Microsoft-IIS/7.5 X-AspNetMvc-Version: 4.0 Content-Disposition: attachment; filename=UTF-8''MyVideo.MOV X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Sat, 29 Jun 2013 05:01:32 GMT**

HELP!: I would appreciate any advice on a work-around. Also, I would appreciate a definite word from somebody who works in the Google dev community as to whether this will be fixed in the next refresh. Thanks!!

TheDude
  • 1,421
  • 4
  • 29
  • 54
  • Can you post a link that would allow us to see the behavior for ourselves and see if there's anything noteworthy in the response headers that might explain this? – CommonsWare Jun 28 '13 at 22:36
  • I captured the response headers using chrome dev tools. Here it is: HTTP/1.1 200 OK Cache-Control: private, s-maxage=0 Content-Length: 54295903 Content-Type: application/octet-stream Server: Microsoft-IIS/7.5 X-AspNetMvc-Version: 4.0 Content-Disposition: attachment; filename*=UTF-8''MyVideo.MOV X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Sat, 29 Jun 2013 05:01:32 GMT – TheDude Jun 29 '13 at 05:04
  • Could it have something to do with prepending UTF-8 to the file name? There's no effect on the desktop chrome browser, but it could possibly have an effect on the android chrome browser? What do you think? – TheDude Jun 29 '13 at 05:07
  • Sorry, my mistake, someone asked the same question the other day it is fixed in Beta you need to wait until that becomes the standard version of Chrome. – Kinlan Jul 01 '13 at 15:30
  • OK, someone deleted the question. – Kinlan Jul 01 '13 at 15:31
  • http://stackoverflow.com/questions/17239264/i-cant-open-local-files-from-filesystem-api-on-my-android-phone/17277124#17277124 is the answer to a similar question. – Kinlan Jul 01 '13 at 15:32
  • Oh it was you, I answered it Live on Air - https://www.youtube.com/watch?v=rXLNC8yCRnw&feature=player_detailpage#t=282s – Kinlan Jul 01 '13 at 15:34

4 Answers4

3

Content-Disposition has a history of being a problem on Android. You are certainly welcome to try removing the UTF-8 part and see if that helps Chrome. But definitely test the original Android Browser app as well, as numerically that's the most popular browser for Android.

See also:

Community
  • 1
  • 1
CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thanks. Very helpful. I will try modifying the Content-Disposition. Another thing to note is that the Content-Disposition is set to: filename*=UTF-8"MyVideo.MOV In the examples I've seen, that * before the = in my case doesn't seem to belong. Do you think that may be confusing the Android Chrome browser? – TheDude Jun 29 '13 at 20:37
2

I had a similar problem with downloads on Chrome/Android. .docx files were renamed to filename.bin (or something like that).

Headers included 

Content-Type:application/octet-stream

and

Content-Disposition:attachment; filename="something.docx";

Turned out that my problem was in trailing semicolon in "Content-Disposition" header. When there is no semicolon at the end of the line - it works fine:

Content-Disposition:attachment; filename="something.docx"

More info here: http://www.digiblog.de/2011/04/android-and-the-download-file-headers/

So, be sure to check that as well.

Rajesh Paul
  • 6,793
  • 6
  • 40
  • 57
Anton Laptashev
  • 151
  • 3
0

This a duplicate of a previous question we answered live on air and on SO here https://stackoverflow.com/questions/17266320/chrome-browser-in-android-always-renames-downloaded-file-to-download-bin which has been deleted.

This will be fixed in the next refresh especially via the a[download] attribute.

Community
  • 1
  • 1
Kinlan
  • 16,315
  • 5
  • 56
  • 88
  • Hey Kinlan, I appreciate you trying to help me out and apologize for not providing more details. It turns out the Android Chrome browser seems to have a problem with UTF-8 encoding in the file name. In our code, we're encoding the file name with UTF-8 encoding to handle non-ascii characters. But, the Android Chrome browser seems to choke on that since it downloads correctly when I take the UTF-8 part out – TheDude Jul 01 '13 at 17:59
  • The Spec for disposition has no mention of UTF-8 being valid at all, so I think it should be taken out as per the answer above. – Kinlan Jul 04 '13 at 16:44
  • So how will android chrome handle non-ascii characters in file names in the future? The desktop Chrome browser is able to handle the utf-8 encoding of the file name in content-disposition, btw. – TheDude Jul 05 '13 at 02:38
  • I'm starting to wonder if the Android Chrome browser behaves differently from the desktop version and doesn't require UTF-8 encoding. I'll have to test out file names with non-ascii characters on the Android Chrome browser. I'll let you guys know... – TheDude Jul 05 '13 at 03:01
  • 1
    OK. It looks like I was able to successfully download a file with Korean characters in it using Android Chrome. I didn't have to encode it with UTF-8. – TheDude Jul 05 '13 at 03:56
0

For my particular case, I was downloading a kmz file. This is a kml file (map data) zipped up. My Content-Disposition was attachment;filename=export.kmz, but the file would save as export.kmz.zip on Chromium on Android.

My solution was to look at Content-Type. I had not set that header at all, so I guess Chromium assumed it was a normal zip file. I decided to check if there was a kmz content type. Sure enough, I found this link and followed the iana link within:

What are all the possible values for HTTP "Content-Type" header?

And found that the value should be application/vnd.google-earth.kmz. With this change in place, it didn't rename my file.

So, one other possible solution among the others here: see if your content type is correct, and specific enough.

orblivion
  • 446
  • 3
  • 12