On Mon, Mar 25, 2013 at 9:00 AM, Thad Humphries <thad.humphr...@gmail.com>wrote:
> On Sun, Mar 24, 2013 at 4:46 PM, Konstantin Kolinko
> <knst.koli...@gmail.com>wrote:
>
> > 2013/3/25 Thad Humphries <thad.humphr...@gmail.com>:
> > > I have a web-app that uses a servlet for downloading files from a
> > > repository--PDF, Office, images, zip, etc. It works with desktop
> > > browsers--IE, Firefox, Chrome, and Safari--on their various platforms.
> It
> > > also works fine with Firefox from Android (2.3 and 4.x tested). However
> > > when I try with Android's default WebKit browser, the servlet fails
> > > immediately with org.apache.catalina.connector.ClientAbortException (so
> > > says the stderr log).
> >
> > 1. Is this issue specific to some kind of files, or it occurs with all of
> > them?
> >
>
> All of them--PDF, XLS, DOC, DOCX, TIFF, ZIP, etc. Every file type I've
> tried.
>
Hmmm, interesting thread (and responses so far). I think I am aware of this
'Android default Webkit browser' you are referring to. I always avoid using
it, and download Google Chrome from Google Play store to my Android
devices, and I don't think I ever tested my web app with the default
browser installed on Android devices.
I have downloaded PDF files (generated in-memory) from my java/JSF web app
to Android device, and I have never seen this ClientAbortException. my web
app also has at least one iPad enduser (which has Google Chrome installed
on iPad). I am unaware of his experience and I don't think he downloads PDF
files from web app to his iPad, but I am quite confident that it works or
will work. :)
> >
>
> > I suspect this is a problem with mobile WebKit, and that circumventing
> > the
> > > abort might be a "bad thing" even if it's possible. However I thought
> I'd
> > > inquire here if there is a Tomcat way around it. If not, it seems my
> > > alternatives are (1) use Java Mail to mail the user the file, since
> mail
> > > apps open their attachments; and (2) write iOS and Android apps file
> > query
> > > and downloading. Neither prospect thrills me.
>
Okay, i just tested this with/in my web app on my Google Nexus 7 (android,
of course). I offer Download, Print, and View hyperlinks within the web
app. Mind you, this is PrimeFaces xhtml below.
---download---
<p:commandLink value="Download" ajax="false"
actionListener="#{pf_ordersController.refreshContractsToDownload()}">
<p:fileDownload value="#{contractToDownload.file}"/>
</p:commandLink>
Test and results:
clicked Download button, PDF downloaded to Google Nexus 7 (Google Chrome
browser, of course), showed up in notifications, instead of PDF Viewer app,
I selected to open the PDF document in Adobe Acrobat (app that was
downloaded from Google Play).
---view---
<h:commandLink value="View" target="_blank"
actionListener="#{pf_ordersController.refreshContractsToDownload()}">
<p:fileDownload value="#{contractToDownload.file}"
contentDisposition="inline"/>
</h:commandLink>
Test and results:
clicked View button, I saw another web page tab open rather quickly in the
Google Chrome browser on Google Nexus 7, and then the new tab closed
immediately, and then I saw the 'Starting download' toast (at bottom of
Google Nexus 7), but I didn't see the file in notifications or downloads,
and I didn't see any exceptions in my TomEE/tomcat7 logs.
With that said, maybe I just duplicated this issue/exception that you have
been experiencing. If I'm not mistaking, PrimeFaces is using the servlet
solution for file downloads.
So, based on this test of mine, it is best to offer a 'download' hyperlink
'only' on mobile devices as I am already detecting mobile devices when they
login to the web app.
Thanks for this topic. now I know what i 'need' to do. :)
