问题
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!
回答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
回答2:
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!
回答3:
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
来源：https://stackoverflow.com/questions/9375997/android-2-2-and-2-3-pdf-download-via-https-seems-broken