epub download failure on Android/WebKit browser, and general browser weirdness

Question

I'm trying to setup a servlet so that users on Android handsets/tablets (using the default browser) can fill out a form and post a few parameters to a servlet, then the servlet applies some logic to pick a pre-existing epub file to stream back in response. Seems simple enough, but it's giving me all kinds of fits.

The setup: the Android user visits my site and submits the form, the servlet in Weblogic 10.3 picks my one test epub file to stream back in response, sets a Content-Type of application/epub+zip, sets a Content-Disposition of attachment; filename=TestPartsManual.epub, streams the bytes back to the device.

It works just fine in Chrome, where I'm doing all primary development because of theoretical WebKit sameness and its cool developer tools.

But when I try things on my Android handset (Tmobile Vibrant Galaxy S) using the default browser (User-Agent: Mozilla/5.0 (Linux; U; Android 2.1-update1; en-us; SGH-T959 Build/ECLAIR) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17) with Aldiko installed (and working), it always fails, no contents in the response, Weblogic reporting a socket write error. So I turned on Wireshark and saw some odd things going on:

1. As soon as the form is POSTed to '/demoapp/partsmanual', the handset promptly closes the connection. Weblogic reports the socket write error.
2. The browser screen flips over to the download list and says it is trying to download 'partsmanual.bin'
3. The handset sends in a new request to GET '/demoapp/partsmanual', but without any of the form parameters the servlet doesn't know what file to send back, and nothing gets sent back.

So, any idea why it suddenly doesn't like the form POST and unilaterally decides a parameterless GET to the same URI should suffice???

So I simplify things for testing and just provide a link to TestPartsManual.epub, and setup a mime-mapping in web.xml giving the epub extension a mime-type of application/epub+zip. I click on the link, verify via Wireshark the Content-Type is being sent, and things are looking ok:

1. The browser screen flips over to the download list, it says it's downloading TestPartsManual.epub. This is good.
2. The download completes, says it downloaded 216k, Wireshark concurs, and it must have liked the Content-Type because the Aldiko icon is to the left. This is also good.
3. But then when you tap it, it pops up a notice saying 'Your book will be downloaded'. Huh? My book already is downloaded, right?
4. The download status in the status bar then immediately reports the download has failed. It never sent in another GET to the server.

So, any idea why it disregards what's already been downloaded, then reports a download failure without having retried??? The epub file itself, btw, has been validated, copied to my sd card, imported into Aldiko, and it reads it just fine, so I'm not suspicious of the file itself.

**Update** I believe the issue I'm seeing with simply clicking on an epub link can be chalked up to whatever finicky Android epub reader(s) you have installed. Though Google Books 1.0.16, for example, shows epubs, it wants nothing to do with anything you download other than through their service. Aldiko 1.2.14 registers its intent handle the epub mime-type, but then blows up on anything launched from the browser downloads. FBReaderJ seems to have registered its intent to handle links ending in .epub, and it does handle the download and showing them (yay FBReaderJ!), but I can't tell yet if it would handle a form POST solely by mime-type (my original requirement), as I'm growing more convinced my first question above is a browser problem. I'm looking at you, Content-Disposition, even with quoted filenames...

Lastly, (I admit, this is just a tangent) I turn on debugging in Eclipse hooked up to my Weblogic VM to intercept the form post. Maybe I can see something stepping through it. After about 5 seconds or so, it's like the handset browser gets impatient and resubmits the form! Another request comes in to the servlet, and it's picked up by another weblogic thread. What the heck kind of behaviour is that??? Makes me glad I'm not writing a stock trading app....

Answer 1

You can't presently do it. As described, in the Android browser, when you POST a form that responds with an attachment file download, the server's response is stopped, the download manager is launched, and it incorrectly tries a GET to the same URI but without the form parameters. Inexplicably this double request is 'by design' and support for form POSTs is an enhancement, but "don't hold your breath". See http://code.google.com/p/android/issues/detail?id=1780 and 3949.

Until it's fixed, I guess you just have to GET .epub files with a reader who's registered to handle the .epub file extension.