You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Thad Humphries <th...@gmail.com> on 2013/03/24 21:30:57 UTC
Can ClientAbortException be circumvented?
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).
The servlet is sending proper headers, including the correct MIME type,
Content-Disposition attachment, file size, etc. I even took to adding the
file's name as the last GET parameter. No dice.
Safari on iPad, iPhone, and iPod Touch also fail. Although I don't have one
with me at this moment to test, I suspect their failure is also caused by a
ClientAbortException: Safari is also WebKit and *I've Google'd numerous
complaints about this exception when using mobile WebKit browsers*. While I
can tell Android users to try Firefox, there is no Firefox for iPhone.
I'm expecting a file to open in a local viewer app, like Acrobat Reader,
QuickOffice, Pages, etc. I can open files in these apps via Firefox, an
email client, or via the WebKit browser when viewing a directory listing in
my public_html directories and similar locations.
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.
Thoughts?
--
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v, 121-24)
Re: Can ClientAbortException be circumvented?
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Mon, Mar 25, 2013 at 11:58 AM, Howard W. Smith, Jr. <
smithh032772@gmail.com> wrote:
> On Mon, Mar 25, 2013 at 11:54 AM, Howard W. Smith, Jr. <
> smithh032772@gmail.com> wrote:
>
>> On Mon, Mar 25, 2013 at 9:00 AM, Thad Humphries <thad.humphries@gmail.com
>> > wrote:
>>
>>> On Sun, Mar 24, 2013 at 4:46 PM, Konstantin Kolinko
>>> <kn...@gmail.com>wrote:
>>>
>>> > 2013/3/25 Thad Humphries <th...@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. :)
>>
>>
> Forgot to mention; i would definitely provide an option for files to be
> emailed to endusers. my web app has that option as well as it is more
> reliable.
>
> i have found that endusers do a lot of multi-tasking on mobile devices,
> and mobile browsers seem to lose connection when they go to some other app.
> i may not be describing this correctly, but I have noticed this behavior,
> myself.
>
>
UPDATE:
1. Reached out to 2 mobile endusers of my web app that does file downloads
2. iPad enduser says that the View commandLink
(contentDisposition="inline") works 'always', he has no issues
3. Android enduser informed me that the View commandLink
(contentDisposition="inline") 'does not always' work, sometimes it works,
sometimes it does
4. Per the test results, this email thread, and what my endusers want, i
just made a change to 'only' provide the View commandLink
(contentDisposition="inline") to iPad (and nonmobile devices), and the
Download commandlink is provided to Android endusers
Re: Can ClientAbortException be circumvented?
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Mon, Mar 25, 2013 at 11:54 AM, Howard W. Smith, Jr. <
smithh032772@gmail.com> wrote:
> On Mon, Mar 25, 2013 at 9:00 AM, Thad Humphries <th...@gmail.com>wrote:
>
>> On Sun, Mar 24, 2013 at 4:46 PM, Konstantin Kolinko
>> <kn...@gmail.com>wrote:
>>
>> > 2013/3/25 Thad Humphries <th...@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. :)
>
>
Forgot to mention; i would definitely provide an option for files to be
emailed to endusers. my web app has that option as well as it is more
reliable.
i have found that endusers do a lot of multi-tasking on mobile devices, and
mobile browsers seem to lose connection when they go to some other app. i
may not be describing this correctly, but I have noticed this behavior,
myself.
Re: Can ClientAbortException be circumvented?
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Tue, Mar 26, 2013 at 8:42 PM, Howard W. Smith, Jr. <
smithh032772@gmail.com> wrote:
> Chris,
>
> On Tue, Mar 26, 2013 at 4:00 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Howard,
>>
>> On 3/25/13 11:54 AM, Howard W. Smith, Jr. wrote:
>> > 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.
>>
>> What servlet ultimately returns the bytes to the client? If it's
>> Tomcat's DefaultServlet, then - following my line of thought elsewhere
>> in this thread - Range requests are likely being respected.
>>
>
> That's a good question. I'm unable to answer that at the moment. Per your
> question, I'm doing some reading on this now; since this is a JSF web
> application / project, I'm referring to some BalusC blogs/answers on
> stackoverflow. According to this one response of his[1], I assume that I am
> using Tomcat default servlet, but I could be mistaking here. Also, please
> note, my container is TomEE 1.6.0 SNAPSHOT (which is Tomcat 7.0.37,
> currently).
>
> This is the first time I have heard about 'range request', but since you
> mentioned it, I am seeing it mentioned elsewhere.
>
>
> [1] http://stackoverflow.com/a/3428207/933054
>
>
I read your other response to the OP about range request and tomcat
respecting it. I am doing some research and I found the following:
BalusC says, in an older/2009 blog[1], yes obviously it is old, because
back then, he said,
You could leverage the task to a default servlet of the
webcontainer/appserver you're using, but most of them doesn't implement all
of the performance enhancements, so does for example Tomcat's
DefaultServlet<http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html>
*not* support the Expiresheader.
but per what you said, Chris, he also mentioned the following in that blog,
Resume downloads<http://balusc.blogspot.com/2009/02/fileservlet-supporting-resume-and.html#ResumeDownloads>
To enable download resumes, the server have to send at least the
Accept-Ranges<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.5>
, ETag <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19>
and Last-Modified<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.29>
response
headers to the client along with the file.
The Accept-Ranges response header with the value "bytes" informs the client
that the server supports byte-range requests. With this the client could
request for a specific byte range using the
Range<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35>
request
header.
One line from the code below,
externalContext.setResponseHeader("Content-Disposition",
contentDispositionValue + ";filename=\"" + content.getName() + "\"");
shows that the server is not sending a response header containing range
request. Am I correct?
The code below:
public void processAction(ActionEvent actionEvent) throws
AbortProcessingException {
FacesContext facesContext = FacesContext.getCurrentInstance();
ELContext elContext = facesContext.getELContext();
StreamedContent content = (StreamedContent)
value.getValue(elContext);
if(content == null) {
return;
}
ExternalContext externalContext = facesContext.getExternalContext();
String contentDispositionValue = contentDisposition != null ? (String)
contentDisposition.getValue(elContext) : "attachment";
try {
externalContext.setResponseContentType(content.getContentType());
externalContext.setResponseHeader("Content-Disposition",
contentDispositionValue + ";filename=\"" + content.getName() + "\"");
externalContext.addResponseCookie(Constants.DOWNLOAD_COOKIE, "true", new
HashMap<String, Object>());
byte[] buffer = new byte[2048];
int length;
InputStream inputStream = content.getStream();
OutputStream outputStream =
externalContext.getResponseOutputStream();
while ((length = (inputStream.read(buffer))) != -1) {
outputStream.write(buffer, 0, length);
}
externalContext.setResponseStatus(200);
externalContext.responseFlushBuffer();
inputStream.close();
facesContext.responseComplete();
}
catch(IOException e) {
throw new FacesException(e);
}
}
[1]
http://balusc.blogspot.com/2009/02/fileservlet-supporting-resume-and.html
>
>> - -chris
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBCAAGBQJRUf5VAAoJEBzwKT+lPKRYd9EQAJIKMPy+h/ULF2pCfjQ7lKpD
>> IlPc5k35YwHxfNu1l1HKuP2Fn/RdynxmtHdE5bcNfgvaEMN8ogRTgcAf0obROwDt
>> xKHPLcX9D44+wc0tB3YWTrbXio8RnVsQDAChjrYUapANlTgclQWidNR2lqnHRtKZ
>> j5DDqGQ9Rh9mQsvLU4/vtWXwm+MBwlluI0KfTnVVFNHH8hbtHi3bkUBrrUr5CBok
>> afjU1URh7NKkgtVLfAzI9mWvsdlVDjdb6W/Hz2+bbcZjM13o833+h8TbxRrNbfyX
>> DSRv75WjKTIaBwnEdNUG2ScqfudCdJZXwOz4UdaBNClzE0wLx2Jc0Tdd4cpjaXec
>> mOXYlbUzZf2hbHOIltKP6BmzhIx83g8c2971yKTPI1b19nPae+QTSSeJJEDBchVA
>> v0nNQWIZ1lNSS0X60FPIshOlZvQokOHYV1muYvSZjzu07PlT7yGwbhvtMXKncIDd
>> 1TKIXAhCvF9kpBw2JAkx8cDaBfW1o5IXcJA85IXS+y2lvIzc7tNOetDCj7C3PHAk
>> jEy6FPqV475X1cOXgLkLX5WRAJEuyZ3TuOpFDYsOJo39zqmzw5BPwLCL5rfCW+r5
>> 5GZyXjSurGqL8Sw/Jy4HpUGSWEBqOXqtctG9QpqzSdOv5uMz2uvqcoO49ADdUQTF
>> rQHGMaf8KJl83fykc8np
>> =d8sp
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
Re: Can ClientAbortException be circumvented?
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Chris,
On Tue, Mar 26, 2013 at 4:00 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Howard,
>
> On 3/25/13 11:54 AM, Howard W. Smith, Jr. wrote:
> > 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.
>
> What servlet ultimately returns the bytes to the client? If it's
> Tomcat's DefaultServlet, then - following my line of thought elsewhere
> in this thread - Range requests are likely being respected.
>
That's a good question. I'm unable to answer that at the moment. Per your
question, I'm doing some reading on this now; since this is a JSF web
application / project, I'm referring to some BalusC blogs/answers on
stackoverflow. According to this one response of his[1], I assume that I am
using Tomcat default servlet, but I could be mistaking here. Also, please
note, my container is TomEE 1.6.0 SNAPSHOT (which is Tomcat 7.0.37,
currently).
This is the first time I have heard about 'range request', but since you
mentioned it, I am seeing it mentioned elsewhere.
[1] http://stackoverflow.com/a/3428207/933054
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJRUf5VAAoJEBzwKT+lPKRYd9EQAJIKMPy+h/ULF2pCfjQ7lKpD
> IlPc5k35YwHxfNu1l1HKuP2Fn/RdynxmtHdE5bcNfgvaEMN8ogRTgcAf0obROwDt
> xKHPLcX9D44+wc0tB3YWTrbXio8RnVsQDAChjrYUapANlTgclQWidNR2lqnHRtKZ
> j5DDqGQ9Rh9mQsvLU4/vtWXwm+MBwlluI0KfTnVVFNHH8hbtHi3bkUBrrUr5CBok
> afjU1URh7NKkgtVLfAzI9mWvsdlVDjdb6W/Hz2+bbcZjM13o833+h8TbxRrNbfyX
> DSRv75WjKTIaBwnEdNUG2ScqfudCdJZXwOz4UdaBNClzE0wLx2Jc0Tdd4cpjaXec
> mOXYlbUzZf2hbHOIltKP6BmzhIx83g8c2971yKTPI1b19nPae+QTSSeJJEDBchVA
> v0nNQWIZ1lNSS0X60FPIshOlZvQokOHYV1muYvSZjzu07PlT7yGwbhvtMXKncIDd
> 1TKIXAhCvF9kpBw2JAkx8cDaBfW1o5IXcJA85IXS+y2lvIzc7tNOetDCj7C3PHAk
> jEy6FPqV475X1cOXgLkLX5WRAJEuyZ3TuOpFDYsOJo39zqmzw5BPwLCL5rfCW+r5
> 5GZyXjSurGqL8Sw/Jy4HpUGSWEBqOXqtctG9QpqzSdOv5uMz2uvqcoO49ADdUQTF
> rQHGMaf8KJl83fykc8np
> =d8sp
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Can ClientAbortException be circumvented?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Howard,
On 3/25/13 11:54 AM, Howard W. Smith, Jr. wrote:
> 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.
What servlet ultimately returns the bytes to the client? If it's
Tomcat's DefaultServlet, then - following my line of thought elsewhere
in this thread - Range requests are likely being respected.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRUf5VAAoJEBzwKT+lPKRYd9EQAJIKMPy+h/ULF2pCfjQ7lKpD
IlPc5k35YwHxfNu1l1HKuP2Fn/RdynxmtHdE5bcNfgvaEMN8ogRTgcAf0obROwDt
xKHPLcX9D44+wc0tB3YWTrbXio8RnVsQDAChjrYUapANlTgclQWidNR2lqnHRtKZ
j5DDqGQ9Rh9mQsvLU4/vtWXwm+MBwlluI0KfTnVVFNHH8hbtHi3bkUBrrUr5CBok
afjU1URh7NKkgtVLfAzI9mWvsdlVDjdb6W/Hz2+bbcZjM13o833+h8TbxRrNbfyX
DSRv75WjKTIaBwnEdNUG2ScqfudCdJZXwOz4UdaBNClzE0wLx2Jc0Tdd4cpjaXec
mOXYlbUzZf2hbHOIltKP6BmzhIx83g8c2971yKTPI1b19nPae+QTSSeJJEDBchVA
v0nNQWIZ1lNSS0X60FPIshOlZvQokOHYV1muYvSZjzu07PlT7yGwbhvtMXKncIDd
1TKIXAhCvF9kpBw2JAkx8cDaBfW1o5IXcJA85IXS+y2lvIzc7tNOetDCj7C3PHAk
jEy6FPqV475X1cOXgLkLX5WRAJEuyZ3TuOpFDYsOJo39zqmzw5BPwLCL5rfCW+r5
5GZyXjSurGqL8Sw/Jy4HpUGSWEBqOXqtctG9QpqzSdOv5uMz2uvqcoO49ADdUQTF
rQHGMaf8KJl83fykc8np
=d8sp
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Can ClientAbortException be circumvented?
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Mon, Mar 25, 2013 at 9:00 AM, Thad Humphries <th...@gmail.com>wrote:
> On Sun, Mar 24, 2013 at 4:46 PM, Konstantin Kolinko
> <kn...@gmail.com>wrote:
>
> > 2013/3/25 Thad Humphries <th...@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. :)
Re: Can ClientAbortException be circumvented?
Posted by Thad Humphries <th...@gmail.com>.
On Mon, Mar 25, 2013 at 10:02 AM, Brett Delle Grazie <
brett.dellegrazie@gmail.com> wrote:
> On 25 March 2013 13:00, Thad Humphries <th...@gmail.com> wrote:
>
> > On Sun, Mar 24, 2013 at 4:46 PM, Konstantin Kolinko
> > <kn...@gmail.com>wrote:
> >
> > > 2013/3/25 Thad Humphries <th...@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.
> >
> >
> > > 2. If client aborts a connection, there is nothing much a server can
> > > do. It is issue in your web browser.
> > >
> >
> > Yeah, I suspected that.
> >
> >
> > > > The servlet is sending proper headers, including the correct MIME
> type,
> > > > Content-Disposition attachment, file size, etc. I even took to adding
> > the
> > > > file's name as the last GET parameter. No dice.
> > >
> > > 3. Maybe the browser does not like "Content-Disposition attachment"?
> > > Maybe it cannot save the file?
> > >
> >
> > These same file types can be downloaded if the servlet is called by
> > Firefox, or if the file is requested from a directory listing or in an
> > email attachment. In these cases, with Android they go to the Downloads
> > directory on the memory card; on iPad, DOCs open in Pages, PDFs in a
> > viewer, etc.
> >
> >
> > > 4. Does it depend on file size? How the file is served? (What
> > > connector implementation are you using? Do you use compression, do you
> > > use sendfile?)
> > >
> >
> > Size does not matter, a few K or a several hundred K.
> >
> > > Safari on iPad, iPhone, and iPod Touch also fail. Although I don't have
> > > one
> > > > with me at this moment to test, I suspect their failure is also
> caused
> > > by a
> > > > ClientAbortException: Safari is also WebKit and *I've Google'd
> numerous
> > > > complaints about this exception when using mobile WebKit browsers*.
> > > While I
> > > > can tell Android users to try Firefox, there is no Firefox for
> iPhone.
> > > >
> > > > I'm expecting a file to open in a local viewer app, like Acrobat
> > Reader,
> > > > QuickOffice, Pages, etc. I can open files in these apps via Firefox,
> an
> > > > email client, or via the WebKit browser when viewing a directory
> > listing
> > > in
> > > > my public_html directories and similar locations.
> > > >
> > > > 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.
> >
>
> Is this over HTTPS or standard HTTP?
Standard HTTP.
The servlet opens the file from the repository using the repository's API,
sends the HTTP header, then reads the file (again with the API) and sends
the bytes to ServletOutputStream. The file is read and written in blocks
of response.getBufferSize() or 8K if that call returns zero.
--
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v, 121-24)
Re: Can ClientAbortException be circumvented?
Posted by Brett Delle Grazie <br...@gmail.com>.
On 25 March 2013 13:00, Thad Humphries <th...@gmail.com> wrote:
> On Sun, Mar 24, 2013 at 4:46 PM, Konstantin Kolinko
> <kn...@gmail.com>wrote:
>
> > 2013/3/25 Thad Humphries <th...@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.
>
>
> > 2. If client aborts a connection, there is nothing much a server can
> > do. It is issue in your web browser.
> >
>
> Yeah, I suspected that.
>
>
> > > The servlet is sending proper headers, including the correct MIME type,
> > > Content-Disposition attachment, file size, etc. I even took to adding
> the
> > > file's name as the last GET parameter. No dice.
> >
> > 3. Maybe the browser does not like "Content-Disposition attachment"?
> > Maybe it cannot save the file?
> >
>
> These same file types can be downloaded if the servlet is called by
> Firefox, or if the file is requested from a directory listing or in an
> email attachment. In these cases, with Android they go to the Downloads
> directory on the memory card; on iPad, DOCs open in Pages, PDFs in a
> viewer, etc.
>
>
> > 4. Does it depend on file size? How the file is served? (What
> > connector implementation are you using? Do you use compression, do you
> > use sendfile?)
> >
>
> Size does not matter, a few K or a several hundred K.
>
> > Safari on iPad, iPhone, and iPod Touch also fail. Although I don't have
> > one
> > > with me at this moment to test, I suspect their failure is also caused
> > by a
> > > ClientAbortException: Safari is also WebKit and *I've Google'd numerous
> > > complaints about this exception when using mobile WebKit browsers*.
> > While I
> > > can tell Android users to try Firefox, there is no Firefox for iPhone.
> > >
> > > I'm expecting a file to open in a local viewer app, like Acrobat
> Reader,
> > > QuickOffice, Pages, etc. I can open files in these apps via Firefox, an
> > > email client, or via the WebKit browser when viewing a directory
> listing
> > in
> > > my public_html directories and similar locations.
> > >
> > > 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.
>
Is this over HTTPS or standard HTTP?
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
>
> --
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v, 121-24)
>
--
Best Regards,
Brett Delle Grazie
Re: Can ClientAbortException be circumvented?
Posted by Thad Humphries <th...@gmail.com>.
On Sun, Mar 24, 2013 at 4:46 PM, Konstantin Kolinko
<kn...@gmail.com>wrote:
> 2013/3/25 Thad Humphries <th...@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.
> 2. If client aborts a connection, there is nothing much a server can
> do. It is issue in your web browser.
>
Yeah, I suspected that.
> > The servlet is sending proper headers, including the correct MIME type,
> > Content-Disposition attachment, file size, etc. I even took to adding the
> > file's name as the last GET parameter. No dice.
>
> 3. Maybe the browser does not like "Content-Disposition attachment"?
> Maybe it cannot save the file?
>
These same file types can be downloaded if the servlet is called by
Firefox, or if the file is requested from a directory listing or in an
email attachment. In these cases, with Android they go to the Downloads
directory on the memory card; on iPad, DOCs open in Pages, PDFs in a
viewer, etc.
> 4. Does it depend on file size? How the file is served? (What
> connector implementation are you using? Do you use compression, do you
> use sendfile?)
>
Size does not matter, a few K or a several hundred K.
> Safari on iPad, iPhone, and iPod Touch also fail. Although I don't have
> one
> > with me at this moment to test, I suspect their failure is also caused
> by a
> > ClientAbortException: Safari is also WebKit and *I've Google'd numerous
> > complaints about this exception when using mobile WebKit browsers*.
> While I
> > can tell Android users to try Firefox, there is no Firefox for iPhone.
> >
> > I'm expecting a file to open in a local viewer app, like Acrobat Reader,
> > QuickOffice, Pages, etc. I can open files in these apps via Firefox, an
> > email client, or via the WebKit browser when viewing a directory listing
> in
> > my public_html directories and similar locations.
> >
> > 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.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v, 121-24)
Re: Can ClientAbortException be circumvented?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/3/25 Thad Humphries <th...@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?
2. If client aborts a connection, there is nothing much a server can
do. It is issue in your web browser.
> The servlet is sending proper headers, including the correct MIME type,
> Content-Disposition attachment, file size, etc. I even took to adding the
> file's name as the last GET parameter. No dice.
3. Maybe the browser does not like "Content-Disposition attachment"?
Maybe it cannot save the file?
4. Does it depend on file size? How the file is served? (What
connector implementation are you using? Do you use compression, do you
use sendfile?)
> Safari on iPad, iPhone, and iPod Touch also fail. Although I don't have one
> with me at this moment to test, I suspect their failure is also caused by a
> ClientAbortException: Safari is also WebKit and *I've Google'd numerous
> complaints about this exception when using mobile WebKit browsers*. While I
> can tell Android users to try Firefox, there is no Firefox for iPhone.
>
> I'm expecting a file to open in a local viewer app, like Acrobat Reader,
> QuickOffice, Pages, etc. I can open files in these apps via Firefox, an
> email client, or via the WebKit browser when viewing a directory listing in
> my public_html directories and similar locations.
>
> 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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Can ClientAbortException be circumvented?
Posted by Thad Humphries <th...@gmail.com>.
On Wed, Mar 27, 2013 at 6:09 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Thad,
>
> On 3/27/13 5:20 PM, Thad Humphries wrote:
> > On Tue, Mar 26, 2013 at 3:56 PM, Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> > Thad,
> >
> > Coming a little late to the party...
> >
> > On 3/24/13 4:30 PM, Thad Humphries wrote:
> >>>> 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).
> >
> > This smells like it might be a Range request issue. Is the client
> > sending a Range header along with the request? Are you respecting
> > it?
> >
> >
> >> I don't see a Range header from my servlet. Here's the request;
> >
> >> GET
> >>
> /myapp/webclient/copyObjectServlet?tag=0oATVXQD1B_l4Vzpw9n1X1EeKIXTKk6d&name=grilled_romaine.doc
> >>
> >>
> HTTP/1.1
> >> Host: 10.1.2.1:8080 Accept-Encoding: gzip Accept-Language: en-US
> >> x-wap-profile:
> >> http://www.htcmms.com.tw/Android/Common/Ace/A9192-1.0.xml Cookie:
> >> JSESSIONID=0AACB4E188B2B68605FE0189C007F7BB Accept-Charset:
> >> utf-8, iso-8859-1, utf-16, *;q=0.7 Referer:
> >> http://10.1.2.1:8080/myapp/?id=ipad&ref=267 Keep-Alive: 115
> >> User-Agent: Mozilla/5.0 (Linux; U; Android 2.3.5; en-us;
> >> HTC-A9192/1.0 Build/GRJ90) AppleWebKit/533.1 (KHTML, like Gecko)
> >> Version/4.0 Mobile Safari/533.1 x-att-deviceid: HTC-A9192/1.0
> >> Connection: keep-alive Accept:
> >>
> application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> >
> >> Here's the response:
> >
> >> HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Expires: 0
> >> Cache-Control: private Pragma: cache Content-Disposition:
> >> attachment; filename="grilled_romaine.doc" Content-Type:
> >> application/msword Content-Length: 12288 Date: Wed, 27 Mar 2013
> >> 20:46:02 GMT
>
> Hmm... and this particular request/response pair resulted in a
> ClientAbortException?
>
> Any idea how many bytes were sent before the exception?
>
> - -chris
>
Yes, that's what I'm seeing, at least when I use a *mobile* WebKit browser.
Desktop Chrome and Safari are fine. So I don't think the problem is Tomcat.
However I raised the issue here in case someone had seen this and had a
Tomcat work around (I dunno any of our customers who are using something
other than Tomcat).
As for how many bytes are sent, in the Wireshark capture I have up now for
a file of 72,704 byte, I see the servlet request, the TCP response with
HTTP header, another TCP, an ACK, two more TCP, a FIN ACK, ACK, and four
RSTs from my Android phone, well before the file is finished.
I'm running Tomcat 7.0.32 with Java 1.7.0_15 on both Windows 7 (64-bit) and
openSUSE 12.3 Linux (32-bit). I'm using straight Tomcat, port 8080, on both
(though I see the same behavior on Linux if I go through Apache 2.4.2 and
mod_jk 1.2.37). Both fail in the same fashion--same sequence when I watch
the wire--but I can see the servlet fail with ClientAbortException in the
Windows tocat7-stderr.*.log (from Commons Daemon procrun since I run Tomcat
as a service). I've cleared the log directory immediately before starting
Tomcat, so I believe the resets I see in Wireshark and the
ClientAbortException are related.
It seems pretty definite that the problem is *not* with Tomcat, but with
mobile WebKit. Guess I'll look into Howard's suggestion about a mail-to
option.
Thanks for y'all's interest. And thanks to Mark for the tip on Wireshark.
It sure beats tcpdump.
--
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v, 121-24)
Re: Can ClientAbortException be circumvented?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Thad,
On 3/27/13 5:20 PM, Thad Humphries wrote:
> On Tue, Mar 26, 2013 at 3:56 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> Thad,
>
> Coming a little late to the party...
>
> On 3/24/13 4:30 PM, Thad Humphries wrote:
>>>> 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).
>
> This smells like it might be a Range request issue. Is the client
> sending a Range header along with the request? Are you respecting
> it?
>
>
>> I don't see a Range header from my servlet. Here's the request;
>
>> GET
>> /myapp/webclient/copyObjectServlet?tag=0oATVXQD1B_l4Vzpw9n1X1EeKIXTKk6d&name=grilled_romaine.doc
>>
>>
HTTP/1.1
>> Host: 10.1.2.1:8080 Accept-Encoding: gzip Accept-Language: en-US
>> x-wap-profile:
>> http://www.htcmms.com.tw/Android/Common/Ace/A9192-1.0.xml Cookie:
>> JSESSIONID=0AACB4E188B2B68605FE0189C007F7BB Accept-Charset:
>> utf-8, iso-8859-1, utf-16, *;q=0.7 Referer:
>> http://10.1.2.1:8080/myapp/?id=ipad&ref=267 Keep-Alive: 115
>> User-Agent: Mozilla/5.0 (Linux; U; Android 2.3.5; en-us;
>> HTC-A9192/1.0 Build/GRJ90) AppleWebKit/533.1 (KHTML, like Gecko)
>> Version/4.0 Mobile Safari/533.1 x-att-deviceid: HTC-A9192/1.0
>> Connection: keep-alive Accept:
>> application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>
>> Here's the response:
>
>> HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Expires: 0
>> Cache-Control: private Pragma: cache Content-Disposition:
>> attachment; filename="grilled_romaine.doc" Content-Type:
>> application/msword Content-Length: 12288 Date: Wed, 27 Mar 2013
>> 20:46:02 GMT
Hmm... and this particular request/response pair resulted in a
ClientAbortException?
Any idea how many bytes were sent before the exception?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRU24yAAoJEBzwKT+lPKRYYIgP/1ZFfJIPzFl11Vext7mvoxzk
GbzoEscoExWBXo98fcnIx9iq1VvIgPeZrcyR1Q0qDlSWkUlohi84neu8AdCM2jyo
EUTXXwwzEJlIOETngvReHR00FGC8mJohWVnZgv3rFVU8jBQhO9RlFpmTLOkncr0V
zxGYxzrbZ9UEU+/F45WQ3YqzbgJ6aoHJd6gMYttWemerrmuHq/s3MBIXxE2fGXnv
gVg+s6ij924TtB2O5TwYqLdbj/qPAKxqwgI7UyPEvsq1MW6LphcqSQwuw6UvBqxc
dZ8jJddHCv0BJ3Eha2GM8U2wWotLGLMBaWXd4vaE2oAinFn3WyJnhiHUDlzGFbyT
Z7KnS4dzpFtTC3PSxVJHFKP/tZfE4ew/LVHZiEEKjpGLu2NvVTFkXlQyQwzJSL64
O05Tbn/s35+w9pyQT+WFulTEtsJsd4k8bNffWllchm+Kqzcz0G9JhRQtX7e0pV6H
Pz23J9QqRaQremOPKTj0pkKtX02cm4p8C309fBkebCH0XzTka41ky1KUZWVfbuNt
sXF0KevaajylFE8rudrwXIY9/wySb29gNbSdlxSiAykhW91dqCWbC61QIiHBFyZ7
3lhpX1Yi4eCXcwM0FjXytxXELtMWSq9bPQ6thMHhQRNsT3A/XschaXRvxEaIkIM8
6YF/vNPRpTGgzBA/hGUC
=qTPr
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Can ClientAbortException be circumvented?
Posted by Thad Humphries <th...@gmail.com>.
On Tue, Mar 26, 2013 at 3:56 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Thad,
>
> Coming a little late to the party...
>
> On 3/24/13 4:30 PM, Thad Humphries wrote:
> > 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).
>
> This smells like it might be a Range request issue. Is the client
> sending a Range header along with the request? Are you respecting it?
>
I don't see a Range header from my servlet. Here's the request;
GET
/myapp/webclient/copyObjectServlet?tag=0oATVXQD1B_l4Vzpw9n1X1EeKIXTKk6d&name=grilled_romaine.doc
HTTP/1.1
Host: 10.1.2.1:8080
Accept-Encoding: gzip
Accept-Language: en-US
x-wap-profile: http://www.htcmms.com.tw/Android/Common/Ace/A9192-1.0.xml
Cookie: JSESSIONID=0AACB4E188B2B68605FE0189C007F7BB
Accept-Charset: utf-8, iso-8859-1, utf-16, *;q=0.7
Referer: http://10.1.2.1:8080/myapp/?id=ipad&ref=267
Keep-Alive: 115
User-Agent: Mozilla/5.0 (Linux; U; Android 2.3.5; en-us; HTC-A9192/1.0
Build/GRJ90) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile
Safari/533.1
x-att-deviceid: HTC-A9192/1.0
Connection: keep-alive
Accept:
application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Here's the response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Expires: 0
Cache-Control: private
Pragma: cache
Content-Disposition: attachment; filename="grilled_romaine.doc"
Content-Type: application/msword
Content-Length: 12288
Date: Wed, 27 Mar 2013 20:46:02 GMT
> I wouldn't be surprised if what's happening is that you are getting a
> Range request (maybe for the first few hundred bytes) and you are
> ignoring it, returning the entire file. Once the client gets enough
> bytes, it simply closes the connection and the rest of the bytes in
> transit fall on the floor.
>
> If the next request is for the last few hundred bytes (frequently,
> this will happen with ZIP and PDF files, since there is critical
> information at the /end/ of the file) and you return the whole file,
> the client may give up at any point (which IMO is silly) in the same way.
>
> > 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.
>
> If the problem truly is Range-related, you may be able to alter your
> servlet to respect the Range request. Of primary benefit will be that
> you will (probably) be sending fewer bytes over the network, which can
> significantly improve performance. Obviously, the secondary benefit
> will be that you don't get these errors anymore.
>
> Of course, coping with Range requests is non-trivial. Be sure to read
> the RFPs very closely.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJRUf1zAAoJEBzwKT+lPKRYrUIQAITTszTQujDkBaKWTVVDlbB6
> xm3m2K6hQls4T743dTY4hGOSWrTPB3ovBpkkfgm1kGxJQsSsRhrD5t8+BhHIIpE7
> Iax24MBD4XTrvPzEuYlx3DSqx2JZK/iDfkffMfmg6Fq74/j3LoStZdTnmts2nQ0l
> BCi5jtU3TMTZdwkNpVMmEiwomY205QBXqAaIEcjs+BtOtvTQakL80XQS3F1FDaPz
> 315pW2cx9JqwWyjmA+5dqPY9zEQVO1JBou7fwMROO1BJ9wo74UxUFDGGETko6ODm
> 4TGd9QpU4Lwnbu9NrK7PxiEnbNGiUC8JGuADpr9lp/jrgg4PyMtFZIVRNUqX5Vkg
> YDnwZFYlcyfmXVa4xHtYogL+qdPb3E0DM+RFfaFy9ka2Q7gwvGVLpHYNancTCicd
> GkU7Hb4mUSZDyR7AAXfJoaLlHVODs2tue8zix8K8y02Rqb49Bc+YS1BB2WgqQSFC
> 0PJ+Z3kWHbZfiTUcz5ZT7SoQsgPtSuagI9SNBBBeFqn2zOdkNkJcgcQ4OKoqDt71
> g3ocpV2PaBtV0cDoL30DiNwy9byrsUKmjlF2b3oyHh4BfxO9UzKPGfd8kgMDg/X0
> Tq7SbPSBwkoOHUVyNCfzMicS4zz/octolUxCS+k+7kC4rqfz98Ke2t7003OLbRqc
> UOO6QgF6KV62ETx5zBve
> =mn1G
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v, 121-24
Re: Can ClientAbortException be circumvented?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Thad,
Coming a little late to the party...
On 3/24/13 4:30 PM, Thad Humphries wrote:
> 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).
This smells like it might be a Range request issue. Is the client
sending a Range header along with the request? Are you respecting it?
I wouldn't be surprised if what's happening is that you are getting a
Range request (maybe for the first few hundred bytes) and you are
ignoring it, returning the entire file. Once the client gets enough
bytes, it simply closes the connection and the rest of the bytes in
transit fall on the floor.
If the next request is for the last few hundred bytes (frequently,
this will happen with ZIP and PDF files, since there is critical
information at the /end/ of the file) and you return the whole file,
the client may give up at any point (which IMO is silly) in the same way.
> 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.
If the problem truly is Range-related, you may be able to alter your
servlet to respect the Range request. Of primary benefit will be that
you will (probably) be sending fewer bytes over the network, which can
significantly improve performance. Obviously, the secondary benefit
will be that you don't get these errors anymore.
Of course, coping with Range requests is non-trivial. Be sure to read
the RFPs very closely.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRUf1zAAoJEBzwKT+lPKRYrUIQAITTszTQujDkBaKWTVVDlbB6
xm3m2K6hQls4T743dTY4hGOSWrTPB3ovBpkkfgm1kGxJQsSsRhrD5t8+BhHIIpE7
Iax24MBD4XTrvPzEuYlx3DSqx2JZK/iDfkffMfmg6Fq74/j3LoStZdTnmts2nQ0l
BCi5jtU3TMTZdwkNpVMmEiwomY205QBXqAaIEcjs+BtOtvTQakL80XQS3F1FDaPz
315pW2cx9JqwWyjmA+5dqPY9zEQVO1JBou7fwMROO1BJ9wo74UxUFDGGETko6ODm
4TGd9QpU4Lwnbu9NrK7PxiEnbNGiUC8JGuADpr9lp/jrgg4PyMtFZIVRNUqX5Vkg
YDnwZFYlcyfmXVa4xHtYogL+qdPb3E0DM+RFfaFy9ka2Q7gwvGVLpHYNancTCicd
GkU7Hb4mUSZDyR7AAXfJoaLlHVODs2tue8zix8K8y02Rqb49Bc+YS1BB2WgqQSFC
0PJ+Z3kWHbZfiTUcz5ZT7SoQsgPtSuagI9SNBBBeFqn2zOdkNkJcgcQ4OKoqDt71
g3ocpV2PaBtV0cDoL30DiNwy9byrsUKmjlF2b3oyHh4BfxO9UzKPGfd8kgMDg/X0
Tq7SbPSBwkoOHUVyNCfzMicS4zz/octolUxCS+k+7kC4rqfz98Ke2t7003OLbRqc
UOO6QgF6KV62ETx5zBve
=mn1G
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Can ClientAbortException be circumvented?
Posted by Mark Thomas <ma...@apache.org>.
On 24/03/2013 20:30, Thad Humphries wrote:
> Thoughts?
Grab a copy of Wireshark. Take a look at exactly what is going on and
hopefully use that to figure out what is causing the breakage.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org