Forum Discussion

Chad_Roberts_21's avatar
Chad_Roberts_21
Icon for Nimbostratus rankNimbostratus
Jan 08, 2007

Problems downloading files with CACHE-CONTROL header

I asked this in response to a previous thread, but my question went unnoticed... I'll try again here.

I recently tried adding the following simple iRule to one of our web apps. It seemed to work well at first, but problems arose:

when HTTP_RESPONSE {
  HTTP::header insert "PRAGMA" "NO-CACHE"
  HTTP::header insert "CACHE-CONTROL" "NO-CACHE"
}

It works great for the most part... until a user attempts to download a file in IE. I've found a number of sites that talk about problems when downloading files in IE when the CACHE-CONTROL header is present, but I find it hard to believe that this long into the existence of IE it's still just a fact that IE, downloads, and that header cannot ever co-exist. Has anyone else ever run into this? I've also tried adding HTTP::version "1.1" but didn't see improvement.

When a user attempts to download a file, the error is something like this:

Internet Explorer cannot download [file] from [server host name].

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

Any ideas?

6 Replies

  • Hey DBW,

     

     

    I realize that you might be looking for workarounds to this, but have you considered taking the other tack and checking with MS for a fix or other ways to handle the issue? They, or their forums, might have more info on how to work around this MS bug.

     

     

    Here is some additional info:

     

     

     

    http://support.microsoft.com/kb/812935

     

     

    SYMPTOMS

     

    When you try to open a Microsoft Office document or a PDF file by typing an HTTPS Uniform Resource Locator (URL) for the document on the Address bar in Internet Explorer 6 Service Pack 1 (SP1), the document may not open, and you may receive the following error message:

     

     

    Internet Explorer cannot download document.pdf from server

     

     

    CAUSE

     

    This issue may occur if any one or more of the following conditions are true:

     

    •The Do not save encrypted pages to disk check box is selected in Internet Explorer 6.0 SP1.

     

    •The server sends the "Cache-Control: No Store" header.

     

    •The server sends the "Cache-Control: No Cache" header.

     

     

    RESOLUTION

     

    A supported fix is now available from Microsoft, but it is only intended to correct the problem that is described in this article.

     

    ...

     

     

     

    Aaron
  • I'm looking in both routes, but the problem is that while Microsoft does have some documentation on the subject, like the example you gave above, every article of their own that I've come across has been specific to a certain type of scenario. Worse yet, the resolution to each is a patch or specific fix of some kind on the browser side. Because we are a financial institution and the application is for customers, we cannot enforce a requirement that all users using IE (90% or more, no doubt) must install a patch not required by Microsoft in critical updates. In other words, this failure will occur 100% of the time with users running IE browsers unless they install a specific patch, and of course I can't place such a requirement on all of our customers.

     

     

    What I'm hoping to find here is the possibility that someone who understands the cache-control header might also understand the way IE works when it comes to that header. For example, does anyone know of an effective way that I might apply those headers to common traffic while excluding file downloads? I've learned a lot about iRules since we moved our boxes to 9.x, but I still have much to learn about HTTP overall.
  • Found the same problem with PDF, XLS and Java Web Start (JNLP) files.

    IE 6/7 fails to download; Firefox is fine.

    The problem seems to go away if you force the HTTP version in the response status line to 1.0 for all app downloads:

    when HTTP_RESPONSE {
       if { [HTTP::header "Content-Type"] contains "application" } {
          HTTP::version "1.0"
       }
    }

    Seems like a hack, so I'm still looking for a proper solution. Anybody?
  • I am having the same problem with these kind of downloads. I have changed the response from http1.1 to http1.0 but also needed to change the content-type as well on some requests before it would work using the above irule.

     

     

    Has anyone else come across this or does anyone know what kind of problems could occur by changing content-type and the http version?

     

     

    cheers

     

     

    simon
  • Hi

    I have hit this problem recently too. In my case relating to a problem with Internet Explorer not being able to download files from a website over https. Problem doesn't exist in firefox.

    We have got round the problem by forcing the removal of all cache control headers on the virtual servers controlling the affected website. We were concerned that this might mean that data driven downloaded files would cache when we didn't want them too, so we just ensured every download file was generated with a different name on the fly making the caching irrelevant. Low usage 'extranet' type website so cache performance wasn't key, where the functionality was.

    The irule was found elsewhere on DevCentral

     
    when HTTP_RESPONSE { 
         Remove all Cache-Control related headers 
         Solves issue in IE when downloading over https fails
        HTTP::header remove Cache-Control 
        HTTP::header remove Expires
        HTTP::header remove Pragma  
     }
    
  • Hi Perry,

     

    I have the same problem to a customer, that he configured a VS with http profile, I don't know really what is IIS version:

     

     

    https://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/2164392/showtab/groupforums/Default.aspx

     

     

    I use this iRule on below but it doesnt' solve the problem:

     

     

    when HTTP_RESPONSE {

     

    if { [HTTP::header "Content-Type"] contains "application" } {

     

    HTTP::version "1.0"

     

    }

     

    }

     

     

    Did you iRule solve this problem?

     

    Thanks

     

    Fabrizio.