Today I was testing an application on staging server before deployment to production server. One part of the application allows users to download dynamically generated PDF file. When I clicked on the link to download the file, I got the following error.
Unable to download UserFiles.aspx from www.foo.com. Unable to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later.
I was not having any problem with this download on production site. First I thought it could be something in the server code that triggered it. I fired up fiddler and looked at the response. I could see the response has correct PDF content and file name that server generated. So as my routine diagnostic process of web application, I decided to try this on Chrome and FireFox instead of Internet Explorer. I was not too surprised to find that the download link worked perfectly. So it was browser related issue.
After digging through old Microsoft Knowledgebase articles, I found that back in IE6.0 days there was some issue with file downloads from SSL sites when cache-control header was set to no-cache or no-store etc. The KB mentioned that this issue was fixed. Just to make sure, I compared the response headers between working version and broken version, I realized that broken verion was sending headers with no-store, no-cahe set for Cache-Control.
--------- Production ---------- HTTP/1.1 200 OK Cache-Control: private Content-Type: application/pdf Compression-Control: whitespace X-Powered-By: ASP.NET Content-disposition: attachment; filename=538785069.pdf Content-Length: 15379 ----------------------- Testing ---------- HTTP/1.1 200 OK Cache-Control: private,no-cache,no-store,max-age=0, must-revalidate,proxy-revalidate Content-Type: application/pdf Compression-Control: whitespace X-Powered-By: ASP.NET Content-disposition: attachment; filename=95736806.pdf Content-Length: 28976 Pragma: no-cache
Then I realized that I have a compression software on server that compresses and adds some cache control headers as well. I turned off the caching headers for these PDF files and everything was back to normal. So much for fixed bug in IE6.0 that shows up in IE8.0.