I'm serving up a .ePub file for download without displaying the url to the client. The code below works in any browser on a PC/Mac but will not work in mobile browsers, at least in Android which is what I have for testing currently. I get a 'download unsuccessful' message every time. Any ideas???
Code:
<cfheader name="content-disposition" value="attachment;filename=#authStuff.lastname#-#theTitle#.ePub" /><cfcontent type="application/unknown" file="d:\home\sample.net\bookSource\#book.ePub#">
all the examples I've seen and used ave a space between the attachment; and the filename, so you could try:
<cfheader name="content-disposition" value="attachment; filename=#authStuff.lastname#-#theTitle#.ePub" />
Also, use FireBug or Fiddler to make sure the header is coming through unaltered. Do desktop browsers prompt you to save with the right filename?
EDIT: Just tried your code out on ios with a pdf and that happily consumed the pdf, so the space may be a red herring, however it makes me think it's probably worth trying out the code below to try to see if it's an ePub thing or a headers thing:
<cfheader name="content-disposition" value="attachment;filename=something.pdf" />
<cfcontent type="application/unknown" file="#expandpath('something.pdf')#">
Try making the following two changes to your code:
1) Wrap the content-disposition filename in quotes (either using doubled up quotes to escape them, or #Chr( 34 )# so they're not confused with your value attribute quotes).
2) Use application/octet-stream as the content type (should really be application/epub+zip but Android doesn't seem to recognize it).
This seems to work on Android 2.3.5 at least.
<cfheader name="content-disposition" value="attachment; filename=#Chr(34)##authStuff.lastname#-#theTitle#.ePub##Chr(34)#">
<cfcontent type="application/octet-stream" file="d:\home\sample.net\bookSource\#book.ePub#">
Related
Executive summary: can't display a pdf file on Android Firefox.
I created an HTML page on my laptop and displayed it using Firefox. The page is a simple menu, consisting solely of links to my wife's sewing machine manuals, like so (skipping over header, title, and stuff, no css, not xhtml):
<p><ul>
<p>
<p><li><a href="file:///storage/3C5D-4F8A/Manual/thing.txt">
<strong>Thing
</strong></a></li>
</p>
<p><li><a href="file:///storage/3C5D-4F8A/Manual/overlockbasics.pdf">
<strong>Overlocking Basics
</strong></a></li></p>
<p><li><a href="file:///storage/3C5D-4F8A/Manual/allaboutthread.pdf">
<strong>All About Thread
</strong></a></li></p>
</p>
...and so on. The goal is to have the manuals handy to the sewing machine. The phone is handy.
On a laptop, clicking the link pops up the associated pdf file, which is expected behavior. However, when I put the HTML file on her phone (and after adjusting the file paths), clicking a link returns a 'unable to download file' message.
To insure I had the correct path at least, I put that 'thing.txt' link in; clicking that returns the contents of the thing.txt file ("This is a thing", if you were wondering), so the path as specified seems correct, and that at least the text display 'plugin' works.
Tried attaching a 'type="application/pdf"' to each anchor tag, but that had no effect. From what I've discovered, Firefox is supposed to have a built-in PDF viewer - a sensible notion - although I have a suspicion that it only works with downloaded files...but if that's true, why does it work on the Win10 laptop? Inquiring minds want to know. True, there are some differences between the two platforms, so perhaps that's just the way things are.
To reiterate, the files I'm trying to display are right there on the phone's storage card.
The phone is a Galaxy S5 sport (android version 6.0.1); Firefox version is 68.3.0.
The laptop is Win10, Firefox version is 71.0.
I see that other people have had problems sort of like this, but their issues appear more complex. This does not seem to be complicated, aside from the common not-working part.
If someone can suggest a solution that doesn't involve third-party add-ons, or reconfiguring Android, or dragging Google into the process, (or as someone suggested elsewhere, writing one's own browser), it's appreciated. Prefer someone pointing out what I'm doing wrong. It's entirely possible that something so simple cannot be simply done.
To see what happens on a Raspberry Pi (mainly because it was handy), I mounted the Samsung as a mts device, modified each anchor tag's path to a single dot/slash preceding the PDF file name, and ran the HTML file into both Firefox ESR, and then Chromium. Oddly, both browsers spontaneously opened and populated tiny PDF windows corresponding to each href; no link click was required. So all that demonstrated is that Firefox behaves differently depending on the platform; I'm glad you were all sitting down for that revelation. Still, it was interesting, in that those browsers had no trouble displaying something. Note I'm not complaining about that; it was just an experiment.
To recap - main interest: Firefox on the Android not displaying PDF when anchor tag clicked.
Thanks.
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!!
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:
http://code.google.com/p/android/issues/detail?id=11422
Android browser/webview bug? Content-Disposition: attachment; filename="xyz.txt"
http://code.google.com/p/android/issues/detail?id=9991
http://thedigiblog.wordpress.com/2011/04/19/android-and-the-download-file-headers/
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.
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.
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.
Ok, there's a long history behind this one, but the gist is that we need to create and download a little bit of text CLIENT side, into a file called "test.lbl". Assume we can't access the server side.
The following code (coffeescript) does this by creating a Blob, converting it to a data url, and then clicking the link. This works GREAT in a desktop Chrome browser. However, in Android Chrome (not sure what version exactly, but I just installed it as of 3/5/13 from Google App Store) this simply won't work. In Android Chrome, the file starts to download and then just spins. (In fact, it shows in your "Ongoing" for quite some time, even after the browser is closed.)
Anyone know why this might not work in Android? Perhaps a different mime type will make it allow the file to be downloaded? We're dealing with internal tablets so we can relax any site specific security settings we need to.
Or, is there a better way to go about this entirely? (client-side generated text file download)
Thanks
$("#get-label").on 'click', (e) ->
e.preventDefault()
bb = new Blob(['test test test'], {type:'text/plain'})
evt = document.createEvent("HTMLEvents")
evt.initEvent("click")
$("<a>", {download: 'test.lbl', href: webkitURL.createObjectURL(bb)}).get(0).dispatchEvent(evt)
This is a known issue in Chrome for Android. I have raised an issue https://code.google.com/p/chromium/issues/detail?id=181032 - if you star that you will be able to see all the updates for it.
I am developing android phonegap application. which has around 65 images (~10kb size for each). My application is working as expected on Ripple chrome plugin as well as on Chrome and FF browser. but when I load it on emulator some images are not able to load.
I have attached screenshot for the reference.
I tried using the jQuery preload plugin but no luck.
Can anyone help me please! Thanks
EDIT:
I have tried the same code without any change on iPhone and WindowsPhone7, Images are showing up fine on both the platform.
Try creating an identical copy of the image (../image_copy1.png, for example), and swap that code out in lieu of the image location that isn't working.
Sometimes emulator programs freak out with file paths either due to localized caching of data or actual logistical errors in the emulator program itself. Dreamweaver has similar problems, as do a host of other dev/testing suites - local caching of images is not an uncommon problem. You can circumvent this issue sometimes by uploading a copy of the desired file (but not copying it within the program itself) - causing a fresh, noncached upload of it. This is by no means a "proper" solution, but it's a quick and dirty workaround for a buggy emu/dev program.
If you are loading the images from an external source, you may need to 'whitelist' the source. Did you add the domain name into the Cordova config file? It is under res/xml/config.xml
<access origin="www.example.com" />
I know that it is necessary for cross domain AJAX requests but not sure for images, you could give it a try.
Can't help much.
Emulator acts cranky some times.
I have faced the issue multiple times.
At the best, you can try creating another avd-image... but at least I cannot guaranttee that it will work.
I have an Activity which is basically a big webview with some other buttons. Normally, I load urls to the webview, and everything works fine. But there is one website, of which all urls are loaded as source files instead of normal html (the browser shows plain text containing the html tags). The strange thing is that using the phone's browser this url loads just fine.
http://pelephone.ynet.mobile1.co.il/default.aspx?N=/ynet/ArticleList.aspx?category=3
Maybe this has something to do with the aspx file? in my laptop computer the url is not loaded, but downloaded as a file. but still, the phone's browser handles it just fine.
Thanks so much for your help!
It's definitely an issue with the URL, or in general with WML URLs.
The mime type of the supplied URL is "text/vnd.wap.wml". Android does not support that,
it displays the source of such pages as plain text. You can find the relevant piece of code
} else if (mMimeType.equals("text/vnd.wap.wml")) {
// As we don't support wml, render it as plain text
mMimeType = "text/plain";
in git://android.git.kernel.org/platform/frameworks/base.git/core/java/android/webkit/LoadListener.java (line 375).
So that's the correct framework behavior (which applies to WebViews).
Im not sure why the browser displays that, basically it should not, and does not here (Tested with an 1.6. and 2.3 emulator and my 2.2. HTC desire). Are you sure your browser is stock? Maybe you are using an alternative browser such as Opera. Or your provider/manufacturer added some wap support for their "premium-content" (if your phone is branded and/or has custom stuff like sense).