通过HTTPS下载的Android 2.2和2.3 PDF文件似乎已经破裂

Question

I've been going nuts about PDF downloads to mobile devices. Here's the next madness, observable on Android 2.2 and 2.3. I couldn't reproduce this problem on iPhones or other devices, neither on Firefox or other desktop browsers.

I'm downloading a PDF via HTTP and it works just fine. Then I'm downloading the same PDF via HTTPS and the download doesn't finish (and the filename is lost):

I'm using these HTTP headers (and others, which are irrelevant here):

Content-Disposition: attachment; filename="abc.pdf"
Content-Type: application/pdf

Changing the Content-Disposition to inline or removing it entirely doesn't help either. Removing the Content-Type will results in displaying the raw binary data in the browser window.

Note: I've already discovered a problem related to untrusted SSL certificates , but that doesn't seem to be the only problem. So I'm really looking for yet another explanation.

Any ideas welcome!

Answer 1

As always, after some hard looking there is an ancient bug report on google code with lots of frustrated developer comments... Here are two open issues related to this problem:

• http://code.google.com/p/android/issues/detail?id=3492
• http://code.google.com/p/android/issues/detail?id=5851

It seems that downloading PDFs using SSL with untrusted certificates (which is the case in my test environment) doesn't work with exactly the symptoms that I have mentioned

Update : That is only one problem. But it doesn't seem to be the only one

Update : As a matter of fact, here is some authoritative information on the whole matter, showing that at the time, Content-Disposition was poorly implemented and specified , which explains many problems encountered when implementing downloads over HTTP:

http://greenbytes.de/tech/tc2231

Answer 2

Besides the certificate validity, the order of the CA chain is also important for the Android download manager to be able to download files.

In order to make sure the intermediate certificates are in the proper order, you can run the following command:

openssl s_client -connect www.google.ch:443 -showcerts | grep ":/[C1]"

This should return a nicely ordered chain such as:

0) subject: server
   issuer:  ca1
1) subject: ca1
   issuer:  ca2
2) subject: ca2
   issuer:  ca3

And not something like this:

0) subject: server
   issuer:  ca1
1) subject: ca2
   issuer:  ca3
2) subject: ca1
   issuer:  ca2

Answer 3

Unable to test this right now as I don't have an https server running anywhere convenient, but does sending Content-Type: application/octet-stream with the headers make any difference?

Obviously, based on your situation and requirements, this may not be an option. Beyond that, try with a valid SSL certificate!