3 Replies Latest reply: May 11, 2011 9:27 AM by Jeff Bloomfield RSS

    QV Server 10 SR1 'Export To Excel' Through Https

      We are running QV Server 10 SR1 with DMS on our app machine, which is communicating with our users through a web proxy sitting in a DMZ. When 'Exporting to Excel' using the Ajax client, it works fine with all browsers except for IE8. When we test using http it seems to work fine, but when switching to https (a requirement at our company) IE8 now fails to retrieve the document.

      Note: we tried the registry fix of 'BypassSSLNoCacheCheck' (according to Microsoft this issue occurs if the server sends a "Cache-control:no-store" header or sends a "Cache-control:no-cache" header), and then everything seems to work fine, but asking all of the users to change their registry is not an option.

      Does anyone have the 'Export To Excel' function working with the Ajax client in an https environment? Any suggestions?

        • QV Server 10 SR1 'Export To Excel' Through Https

          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.

            • QV Server 10 SR1 'Export To Excel' Through Https

              Yeah, I am having similar issues. I'm running IE 9 now and when I click to export it fails and the dialog box comes up, if I click on that, then it works. But this not ideal for users as it can confuse them. The export works fine in Chrome and Firefox. The weird thing is, now my machine will allow me to export with only one click. No idea why this issue is occuring. My "fix" is to make users download the ie plugin and export from there, as that works.


            • QV Server 10 SR1 'Export To Excel' Through Https

              Just confirmed that I was able to download Excel through the server using IE9.  The initial download took awhile for whatever reason, but subequent download were almost immediate.