tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thad Humphries <thad.humphr...@gmail.com>
Subject Re: Can ClientAbortException be circumvented?
Date Wed, 27 Mar 2013 21:20:18 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message