Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Invalid no-cache http headers
Date: Thu, 27 Feb 2003 09:42:00 +0100
Message-ID: <AB6D8A163EBCB94AABD771443C79F9B31EF2CE@nl010se0003.triodos.corp>
Thread-Topic: Invalid no-cache http headers
Thread-Index: AcLdrDIllh7OJ5M6QMm+da0IEuWYnwAhD/NAAAJwmvA=
From: "Dennis van den Berg" <Dennis.vandenBerg@triodos.nl>
To: <tomcat-user@jakarta.apache.org>
Cc: <A.Szwajkajzer@softbank.pl>

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 =3D null;

  public void init(FilterConfig filterConfig) throws ServletException {
    this.filterConfig =3D 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 =3D (HttpServletResponse)response;
    httpResponse.setHeader("Pragma",null);
    httpResponse.setHeader("Cache-Control",null);
    chain.doFilter(request, response);
  }

  public void destroy() {
    filterConfig =3D null;
  }

}

Thanks for any replies,

Dennis

-----Original Message-----
From: Szwajkajzer Adam [mailto:A.Szwajkajzer@softbank.pl]
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:Dennis.vandenBerg@triodos.nl]
> Sent: Wednesday, February 26, 2003 4:30 PM
> To: tomcat-user@jakarta.apache.org
> Subject: Invalid no-cache http headers
>=20
>=20
> Hi all,
>=20
> I encountered problems with the newer Tomcat 4 versions.
> There are caching-headers set on the response, in case of=20
> URL's with security constraints, which are not set in older=20
> Tomcat 4 versions versions.=20
>=20
> This results in 2 things;
> - The user is not able to use the back-button anymore (This=20
> page has expired, in IE6 anyway)
> - When you send a file as an attachement to the browser the=20
> user gets an open/save dialog.
>   When the user presses open, the file is first put into the=20
> cache and then opened (by IE6 anyway)
>   So this results in an 'file not found' message, because=20
> caching is disabled.
>=20
> In the following method in=20
> org.apache.catalina.authenticator.AuthenticatorBase:
>     public void invoke(Request request, Response response,
>                        ValveContext context)
>         throws IOException, ServletException {
>=20
> I found the following code-fragment:
>         // Make sure that constrained resources are not=20
> cached by web proxies
>         // or browsers as caching can provide a security hole
>         if (disableProxyCaching &&=20
>             !(((HttpServletRequest)=20
> hrequest.getRequest()).isSecure())) {
>             HttpServletResponse sresponse =3D=20
>                 (HttpServletResponse) response.getResponse();
>             sresponse.setHeader("Pragma", "No-cache");
>             sresponse.setHeader("Cache-Control", "no-cache");
>             sresponse.setDateHeader("Expires", 1);
>         }
>=20
> 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=20
> are more applicable values for the "Cache-Control" header in=20
> this case. For example "private" or "no-store".
>=20
> Did anyone else encounter any problems of this kind, or did I=20
> overlook something?
>=20
> Thanks for any replies,
>=20
> Dennis
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>=20
>=20

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org