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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]