Android PDF not loading in browser and WebView


I am trying to load PDF files in Android Webview. when i Googled it. the best answer what i found is to use Google Docs. Now What i did is append the PDF file URL at the end of this url

and then load this complete URL in the android WebView. it loads the PDF successfully. But there is one PDF file on the following URL that is not loading in WebView as well as in Chrome browser (on my system). The PDF URL is{16D968D6-198E-4E33-88F4-8A85731CE605}/{05c36123-4df0-4d7d-811c-8b6686fdd526}/external.pdf

and When i try to load the PDF as{16D968D6-198E-4E33-88F4-8A85731CE605}/{05c36123-4df0-4d7d-811c-8b6686fdd526}/external.pdf

then it says No Preview Available. can anyone please tell me whats wrong Here.

Best Solution

This is not a complete answer. I investigated several possibilities but still do not have a convincing explanation for this behavior.

Theory A: URL encoding ... no

My first thought was the same as @gn1 - the curly brackets needed URL encoding. Unfortunately, encoding the url parameter doesn't change the result.

Theory B: Bad PDF file ... no

Next I thought that perhaps Google Docs can't handle this particular PDF file - it's an unsupported version or uses optional features or even has errors that other viewers tolerate. I downloaded a copy and hosted it on another site. When I pointed Google Docs to the new location, it previewed fine.

Theory C: Uncooperative site ... no

Next I thought that maybe this site doesn't cooperate with Google Docs for some reason - perhaps it is blocking Google from indexing it. I found another PDF link on the same site with the same scheme:

When I pointed Google Docs to this link, it previewed fine.

Theory D: Different metadata ... no

Now I had one link that worked and one that didn't. Maybe their metadata was different - e.g. perhaps the one that worked was tagged application/pdf and the other one wasn't. So I looked at the HTTP headers.

Working URL:

HTTP/1.1 200 OK
Cache-Control: max-age=3600
Content-Length: 1767120
Content-Type: application/pdf
Last-Modified: Fri, 02 Nov 2007 12:45:00 GMT
Accept-Ranges: bytes
ETag: "46b1592e4e1dc81:13e6"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Wed, 03 Jun 2015 23:25:23 GMT

Not working URL:

HTTP/1.1 200 OK
Cache-Control: max-age=3600
Content-Length: 4623702
Content-Type: application/pdf
Last-Modified: Mon, 11 May 2015 15:53:16 GMT
Accept-Ranges: bytes
ETag: "acac5d9828cd01:13e6"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Wed, 03 Jun 2015 23:25:42 GMT

I see no apparent significant differences in metadata.

Theory E: Weird request from Google ... no

I'm admittedly grasping at straws at this point. I wondered if the request from Google was different somehow - maybe it asked for a byte range or obscure compression or something, and the target server didn't handle it consistently well. So I pointed Google Docs at a site I control to see what the HTTP request looked like:

GET /asp/in4glestates/%7B16D968D6-198E-4E33-88F4-8A85731CE605%7D/%7B05c36123-4df0-4d7d-811c-8b6686fdd526%7D/External.pdf HTTP/1.1
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (compatible; Google AppsViewer;

That isn't weird at all. I did verify that the target site ignores compression requests so it isn't a case of buggy compression. I also tried accessing the target site with that User-Agent header and it didn't seem to matter.

So I've found clues that help tell us what isn't the problem but nothing yet that explains what is. I'm posting in hopes that these negative results will still be useful to someone.

Related Question