DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27122>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27122 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From [EMAIL PROTECTED] 2007-05-12 09:51 ------- Reopening this bug - even though strictly speaking Tomcat's behaviour is not incorrect - because it seems to be a significant and common source of problems, and is not that easy for the user to diagnose. It occurs with or without SSL, and in a wider set of circumstances than invoking IE plugins. (My own variation is that download to a file in IE fails if a content-disposition header is set and the resource is subject to a security constraint). The workaround given by Bill Barker is to configure each context: <Context path="/myapp" docBase="myapp"> <Valve className="org.apache.catalina.authenticator.FormAuthenticator" disableProxyCaching="false" /> </Context> This works but reduces security more than is necessary, as it causes no cache control headers to be issued at all. An alternative workaround <Context path="/myapp" docBase="myapp"> <Valve className="org.apache.catalina.authenticator.FormAuthenticator" securePagesWithPragma="false" /> </Context> is better. It causes a header Cache-Control: private to be issued in place of the default Cache-Control: none and Pragma: no-cache headers. This tells shared caches not to cache the response, which I think is all that is necessary, while still allowing downloads to work in IE. However, neither workaround is a good solution because it makes configuration more difficult and because it duplicates knowledge of which authenticator is required between the web.xml and context.xml files. Therefore I suggest that AuthenticatorBase be changed to put out the Cache-Control: private header by default. I think this is simply a matter of changing the securePagesWithPragma field from true to false: /** * Flag to determine if we disable proxy caching with headers incompatible * with IE */ protected boolean securePagesWithPragma = true; Other comments in this source file suggest that IE-incompatible headers are being issued because there is some unspecified problem with Mozilla when cache-control: private is used. However I can find no such problem at least with current versions of Firefox. Since the choice therefore seems to be between working around a known bug in all versions of IE, and working around a possible bug in some previous versions of Mozilla that does not affect current Firefox users, I'd argue that the former is the better thing to do. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
