Home/ Questions/Q 6140719
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T18:09:18+00:00

Our product includes a Flash application that is loaded by SWFObject. For one customer,

  • 0

Our product includes a Flash application that is loaded by SWFObject. For one customer, when accessing this SWF via HTTPS (but not HTTP), Flash Player will not load it.

I asked the customer to go directly to the URL of the SWF file (rather than the wrapper page):

  • When he does so via HTTP, the SWF loads in the browser.
  • When he does so via HTTPS, IE7 presents him with a ‘save file’ dialog box. This implies that a “Content-Disposition: attachment” header is present in the response. That would also explain why the SWF isn’t loading in Flash Player: as a security measure, it will not play SWFs served with that header.

So, I have a couple of things I’m trying to figure out:

  1. How can I be certain that a Content-Disposition header is being sent by the server (rather than it being a strange artifact of IE7)? The user only has IE7 at his disposal, and cannot use Firefox, Chrome, etc. IE7 doesn’t include the handy ‘Network’ tab that’s present in IE9’s developer tools.

  2. Assuming that the header is present, how is it getting there? They are running Tomcat 6. The SWF is being served by Tomcat’s default servlet. The header appears to be present if the HTTPS connector is used, but not if the HTTP connector is used. The Tomcat configuration is stock except for enabling the HTTPS connector.

On a side note, I don’t trust Flash’s cache clearing. On my machine under IE9, the SWF is often satisfied by cache even after I explicitly clear the browser cache and Flash Player’s stored data: I don’t see any request for it in Fiddler, or in Tomcat’s access logs, but the SWF loads in the browser. Am I missing something here? Could the customer be accessing some bogus cached version of the SWF?

Edit: Apparently the ‘clear cache’ command in the developer tools doesn’t really clear the cache. Using the standard method yielded the expected results.

Edit 2: Tracing within Tomcat indicates that the Content-Disposition header is not set. I don’t know for certain that it’s not being received by the browser, but AFAIK the browser is connecting directly to Tomcat. This seems like an odd browser-side behavior.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The issue had to do with presence of the following headers in the response:

    Cache-Control: no-cache
Pragma: no-cache

    These were being sent by Tomcat because the page was being protected by a security constraint (configured in conf/web.xml). These headers caused IE7 to act just like a ‘Content-Disposition: attachment‘ header was present.

    My solution was to have the customer add the following configuration to Tomcat’s conf/context.xml:

    <Valve className="org.apache.catalina.authenticator.BasicAuthenticator" securePagesWithPragma="false" />

    This replaces the headers with:

    Cache-Control: private

    …which should still fulfill the goal of preventing proxies from caching the page, while working around IE’s issues. This was based on the solution found here:

    http://daveharris.wordpress.com/2007/07/09/how-to-configure-cache-control-in-tomcat/

    However, that very-similar solution suppressed the headers entirely. Details of these attributes can be found in Tomcat docs here:

    http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Basic_Authenticator_Valve/Attributes

    • 0