java - The Case of The Mysterious Content-Disposition Header -


our product includes flash application loaded swfobject. 1 customer, when accessing swf via https (but not http), flash player not load it.

i asked customer go directly url of swf file (rather wrapper page):

  • when via http, swf loads in browser.
  • when via https, ie7 presents him 'save file' dialog box. implies "content-disposition: attachment" header present in response. explain why swf isn't loading in flash player: security measure, not play swfs served header.

so, have couple of things i'm trying figure out:

  1. how can content-disposition header being sent server (rather being strange artifact of ie7)? user has ie7 @ disposal, , cannot use firefox, chrome, etc. ie7 doesn't include handy 'network' tab that's present in ie9's developer tools.

  2. assuming header present, how getting there? running tomcat 6. swf being served tomcat's default servlet. header appears present if https connector used, not if http connector used. tomcat configuration stock except enabling https connector.

on side note, don't trust flash's cache clearing. on machine under ie9, swf satisfied cache after explicitly clear browser cache , flash player's stored data: don't see request in fiddler, or in tomcat's access logs, swf loads in browser. missing here? customer accessing bogus cached version of swf?

edit: apparently 'clear cache' command in developer tools doesn't really clear cache. using standard method yielded expected results.

edit 2: tracing within tomcat indicates content-disposition header not set. don't know it's not being received browser, afaik browser connecting directly tomcat. seems odd browser-side behavior.

the issue had presence of following headers in response:

cache-control: no-cache pragma: no-cache 

these being sent tomcat because page being protected security constraint (configured in conf/web.xml). these headers caused ie7 act 'content-disposition: attachment' header present.

my solution have customer add following configuration tomcat's conf/context.xml:

<valve classname="org.apache.catalina.authenticator.basicauthenticator" securepageswithpragma="false" /> 

this replaces headers with:

cache-control: private 

...which should still fulfill goal of preventing proxies caching page, while working around ie's issues. based on solution found here:

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

however, very-similar solution suppressed headers entirely. details of these attributes can found in tomcat docs here:

http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#basic_authenticator_valve/attributes


Comments

Popular posts from this blog

c# - SharpSVN - How to get the previous revision? -

c++ - Is it possible to compile a VST on linux? -

url - Querystring manipulation of email Address in PHP -