DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24510>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24510 Odd back button behavior in a multi-frame environment [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From [EMAIL PROTECTED] 2004-01-30 23:51 ------- I wanted to let you know that I found out what was causing the problem (see the following from an old thread on the Tomcat users group). Incidently, it was not limited to framesets. If I filled out a form, went to another page, and then returned to the form (in IE only), my edits would be wiped out. I'm curious as to why the decision was made to automatically send a "no-cache" header repsonse. This seems counter to the tomcat and open source philosophy of maximizing developer control. In any case, here's the thread: RE: Invalid no-cache http headers -------------------------------------------------------------------------------- From: Dennis van den Berg Subject: RE: Invalid no-cache http headers Date: Thu, 27 Feb 2003 00:41:13 -0800 -------------------------------------------------------------------------------- Adam, Your solution should work fine. However, I consider this is a bug, and therefore I wondered if other people agree with me on this point. I used a simple Filter to work around the Tomcat bug; /** * <p>Title: </p> * <p>Description: Reset cache-control headers set by Tomcat. * These headers are set by newer Tomcat versions in the case * the request is for a protected URL. We consider this a bug * in Tomcat. If we do not reset these headers nothing will be * cached, so the back-button will not work properly, and also * in the 'open/save'-dialog, open will not work.</p> * @author Dennis van den Berg * @version 1.0 */ public class CacheControlFilter implements Filter { FilterConfig filterConfig = null; public void init(FilterConfig filterConfig) throws ServletException { this.filterConfig = filterConfig; } public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { /** reset headers set by new Tomcat Connector to enable caching */ HttpServletResponse httpResponse = (HttpServletResponse)response; httpResponse.setHeader("Pragma",null); httpResponse.setHeader("Cache-Control",null); chain.doFilter(request, response); } public void destroy() { filterConfig = null; } } Thanks for any replies, Dennis -----Original Message----- From: Szwajkajzer Adam [mailto:[EMAIL PROTECTED] Sent: donderdag 27 februari 2003 8:30 To: Dennis van den Berg Subject: RE: Invalid no-cache http headers I've found in previouse discussions that "no-cache" feature was added on purpose to "avoid possible security problems". I was told to use JBeans to maintain on server site JSP state. There is no way to switch the feature of. For my current project (intranet application) I just removed setHeader instructions from AuthenticatiorBase, recompiled and had a prevoius behaviour. Hope it helps. Adam Szwajkajzer > -----Original Message----- > From: Dennis van den Berg [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 26, 2003 4:30 PM > To: [EMAIL PROTECTED] > Subject: Invalid no-cache http headers > > > Hi all, > > I encountered problems with the newer Tomcat 4 versions. > There are caching-headers set on the response, in case of > URL's with security constraints, which are not set in older > Tomcat 4 versions versions. > > This results in 2 things; > - The user is not able to use the back-button anymore (This > page has expired, in IE6 anyway) > - When you send a file as an attachement to the browser the > user gets an open/save dialog. > When the user presses open, the file is first put into the > cache and then opened (by IE6 anyway) > So this results in an 'file not found' message, because > caching is disabled. > > In the following method in > org.apache.catalina.authenticator.AuthenticatorBase: > public void invoke(Request request, Response response, > ValveContext context) > throws IOException, ServletException { > > I found the following code-fragment: > // Make sure that constrained resources are not > cached by web proxies > // or browsers as caching can provide a security hole > if (disableProxyCaching && > !(((HttpServletRequest) > hrequest.getRequest()).isSecure())) { > HttpServletResponse sresponse = > (HttpServletResponse) response.getResponse(); > sresponse.setHeader("Pragma", "No-cache"); > sresponse.setHeader("Cache-Control", "no-cache"); > sresponse.setDateHeader("Expires", 1); > } > > I think this piece of code is the source of the problem. > When I read the specs for HTTP, I think I can conclude there > are more applicable values for the "Cache-Control" header in > this case. For example "private" or "no-store". > > Did anyone else encounter any problems of this kind, or did I > overlook something? > > Thanks for any replies, > > Dennis > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
