So, here is what we have been able to determine so far on this issue. To recap, we are on version 10 SR1, are using DMS and Ajax, and only see the issue when using IE 7/8 and when using https.
It appears that for the majority (if not all) of the requests an end user makes when using the Ajax client, the QlikView server responds with "Cache-Control: no-cache, no-store" and "Pragma: no-cache" within the web headers that it returns. This doesn't appear to be an issue when working with http, nor does it even appear to be an issue when requesting a 'print' function within a report (which returns an image file of the chart) when using IE 7/8.
It makes sense as to why caching is disabled, as on dynamically-generated pages you want to ensure that a 2nd fetch gets a new copy of the page, but a side-effect of having a blanket "no-cache" policy is that IE 7/8 (I'm assuming due to built-in settings), tells Excel to go out to the server and get the requested file. However, when doing so it is opening a new tab/window, and that new tab/window is not sharing the authenticated cookie from the original session and so it fails to download the file with an 'unauthenticated user' error.
Note this is different from Chrome or Firefox in the both of those applications will still pull the file down locally and then using Excel to open it up, so there is not an issue using those browsers. It appears that the real issue here is how IE 7/8 is functioning when making a request through https as opposed to http, and I haven't found a way to change any IE settings to accommodate for it.
Has anyone else experienced this, and if so have you found a solution other than only using http? According to QlikView support, this was not an issue in the QVS 9x due to the virtualized QVPrint folders (which no longer exist in version 10). Support is also saying the server is operating as expected and there are no immediate plans to change it.
