Reputation: 1642
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):
So, I have a couple of things I'm trying to figure out:
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.
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.
Upvotes: 1
Views: 2285
Reputation: 1642
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
Upvotes: 2
Reputation: 7661
You should be able to log the outgoing HTTP responses on the server side before encryption, use the null cypher, or provide the RSA keys to wireshark and look at the headers from a packet capture.
Upvotes: 1