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 http://support.microsoft.com/default.aspx?scid=KB;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:
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:
Our problem was actually masked by a number of factors. It turns out, we had two things going on:
…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: