On Wed, Mar 27, 2013 at 6:09 PM, Christopher Schultz < ch...@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 < > > ch...@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)
