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:
http://www.expertagent.co.uk/asp/in4glestates/%7B6dad6f28-a59d-4b54-b277-52f077f4927f%7D/%7Be3a6d17c-d6a8-4e92-8f52-09c6721515fc%7D/External.pdf
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
Host: www.example.com:55555
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (compatible; Google AppsViewer; http://drive.google.com)
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.