Recent Microsoft security updates broke our file download/export function in web site RRS feed

  • Question

  • Our users who use IE8 suddenly cannot download Excel files after Sunday's latest windows updates deployed to our windows 2008 server.

    There is a setting in IE8 Advanced\Security: "Do not save encrypted pages to disk". It's always left with default unchecked. It works fine before. Now when user downloads Excel it throws error: "Internet Explorer cannot download. Internet Explorer was not able to open this internet site. The requested site is either unavaliable or cannot be found. Please try again later."

    If the mentioned setting is checked, it works. But we have another part using Microsoft report viewer. From there we can export Excel file. If the setting is checked, that one will break and not work. Only if the setting is unchecked, the report export will work.

    IE9 works fine with setting unchecked. However our users are hesitant to upgrade to IE9. Any suggestions what we can do solve this issue? Any programmatic way, or what changed in server caused this?




    Friday, January 13, 2012 4:55 PM

All replies

  • We are having the same exact problem. Let's please share findings as we progress through this problem.



    Tuesday, January 17, 2012 5:09 PM
  • I'm having the same issue after 2008 security update.

    Any updates on this?

    Wednesday, January 18, 2012 1:09 AM
  • We're getting Microsoft support involved. But it's been one week and no progress. Very slow response!!
    Friday, January 20, 2012 4:20 PM
  • We were able to work around this issue by modifying the header information being passed along with the stream. Please see below.



    our implementation



            Response.Buffer = True

            Response.BufferOutput = True

            Response.ContentType = "application/x-download"



                            Response.AddHeader("Cache-control", "no-store")

            Response.AddHeader("Content-Disposition", "attachment; filename=" + FileDownloadName)



            Response.OutputStream.Write(bByte, 0, mMemoryStream.Length)




    HTTP headers viewer:


    HTTP/1.1 200 OK

    Cache-Control: no-store,private

    Transfer-Encoding: chunked

    Content-Type: text/html

    Content-Encoding: gzip

    Vary: Accept-Encoding

    X-AspNet-Version: 2.0.50727

    Content-Disposition: attachment; filename=XXXXXXXX.pdf

    X-UA-Compatible: IE=EmulateIE7

    X-Powered-By: ASP.NET

    X-UA-Campatible: IE=EmulateIE7

    Date: Tue, 17 Jan 2012 17:21:43 GMT

    Hope this helps.

    Friday, January 20, 2012 4:55 PM
  • Thanks. But it doesn't work for us. I saw yours is PDF file. Ours is Excel. Don't know if this makes difference. Our response header always comes back with "Cache-control: no cache" although we set it in the code to be private, etc..
    Friday, January 20, 2012 5:08 PM
  • We had problems with both PDF and Excel files and this issue seemed to have resolved both - this is the final production form:

    Response.Buffer = True
    Response.BufferOutput = True
    Response.ContentType = "application/x-download" ‘ use specific content type if known pdf, doc, xls
    Response.AddHeader("Cache-control", "no-store") ‘ these 2 lines are the most crucial – not to save file in cache on local drive – it breaks IE8
    Response.AddHeader("Content-Disposition", "attachment; filename=" + FileDownloadName)Response.OutputStream.Write(bByte, 0, mMemoryStream.Length)

    Friday, January 20, 2012 7:25 PM
  • I tried. It didn't work. Do your XP machine have the MS updates KB2618444? I found if I unstall this update from XP, it will work.
    Friday, January 20, 2012 8:47 PM
  • You have to do it like this

    Response.AddHeader("Cache-Control", " no-store, no-cache ")

    Rather than adding Response.AddHeader("Cache-Control","private")

    More Info

    Wednesday, January 25, 2012 1:46 PM
  • You have to do it like this

    Response.AddHeader("Cache-Control", " no-store, no-cache ")

    Rather than adding Response.AddHeader("Cache-Control","private")

    More Info

    Your suggestion doesn't fix our problem.
    Wednesday, January 25, 2012 4:36 PM
  • We could not get the header changes to work either. What did work for us is calling Response.Flush() before Response.End().
    Tuesday, January 31, 2012 10:14 PM
  • I know it is late but I found the answer to this here:  

    "Web sites that want to allow this type of operation should remove the no-cache header or headers."

    Thursday, February 9, 2012 7:14 PM
  • After two months of struggling with this same issue I was able to get it working again by:

    a. Removing the Vary header


    b. add an ETag header with some random data.

    I hope this helps someone, because nothing else worked for me (and trust me I tried everything).

    Wednesday, February 22, 2012 11:57 PM
  • If you use Java, please setting as follow, it should be working on IE8

    response.reset();    //this line is important





    Wednesday, September 26, 2012 2:25 PM