Haven't done a pcap from the android device, as that's going to require some network setup, but I did check the difference in response headers for an epub pulled directly from it's URL vs. pulling it from the php server.
Here are the response headers for a book pulled from the web server directly (which works with Android):
Code:
HTTP/1.1 200 OK
Date: Mon, 13 Dec 2010 20:18:39 GMT
Server: Apache/1.3.42 (Unix) mod_fastcgi/2.4.6 mod_log_bytes/1.2 mod_bwlimited/1.4 mod_auth_passthrough/1.8 FrontPage/5.0.2.2635 mod_ssl/2.8.31 OpenSSL/0.9.7a
Last-Modified: Sat, 11 Dec 2010 14:29:35 GMT
Etag: "41643c7-9edf8-4d038acf"
Accept-Ranges: bytes
Content-Length: 650744
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/epub+zip
And here are the response headers for a book pulled from the php server:
Code:
HTTP/1.1 200 OK
Date: Mon, 13 Dec 2010 20:17:47 GMT
Server: Apache/1.3.42 (Unix) mod_fastcgi/2.4.6 mod_log_bytes/1.2 mod_bwlimited/1.4 mod_auth_passthrough/1.8 FrontPage/5.0.2.2635 mod_ssl/2.8.31 OpenSSL/0.9.7a
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
X-Powered-By: PHP/5.2.14
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/epub+zip
My money is on the 1981 expiration date. Is this due to a bad configuration on my part, or is this some default that PHP chooses when it's not set anywhere? The Cache-Control rules may also be upsetting Android, maybe it's deciding it's not allowed to let the user save it.