This week, I spent a fair amount of time dealing with a customer who had issues opening up SSRS reports exported into Word, Excel, and PDF. They used both the webform Report Viewer control and a custom control which added a content disposition header for the document type in question to the response and then wrote it out to the browser (see;EN-US;q306654&ID=KB;EN-US;q306654&lex for more details).


While using the Report Viewer, this error got thrown:


Internet Explorer cannot download … from SomeSite

Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later.


When in their custom control, we’d see an error like this (from the app which should have opened the document: Word, Excel, whatever):


The file could not be found. Try one or more of the following:

  • Check the spelling of the name of the document
  • Try a different file name



The customer was also using a third party ISAPI filter to implement security on IIS.


Long story short, we were running into the behavior described in the following article:;en-us;316431


Our problem was actually masked by a number of factors. It turns out, we had two things going on:


  • Even though SSL was not configured on IIS, the customer had an ISAPI filter installed which used SSL under the covers to do encryption
  • The ISAPI also automatically added the CacheControl: no-cache header to the response (You can use Fiddler from to check the headers yourself)


…and as the article above states, if one uses SSL and the no-cache header gets sent down, we will NOT cache the files in question…So we were pretty much deleting the office docs right after they made it to the client, but before we could display them (My customer used filemon to watch iexplore.exe do this, actually)…


So, even though this isn’t really an SSRS problem per-se, here are the takeaways:


  • Verify whether you are using SSL or not, even if you know you haven’t actually configured SSL on your website
  • Use Fiddler to see if the no-cache header is being sent down.