tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Odd behaviour on Expiry-headers
Date Tue, 15 Aug 2006 02:32:13 GMT
You need to call response.setHeader before calling chain.doFilter. 
Otherwise, except for very small responses (like 304) Tomcat will have 
already sent the headers to the browser before chain.doFilter returns.

What you are seeing in the Expires header for your 200 responses is Tomcat's 
default value for secured pages.


"Gregor Schneider" <rc46fi@googlemail.com> wrote in message 
news:a2d59f0d0608141120n51a1ee5bp20f84acc2a183c4a@mail.gmail.com...
> Hi list,
>
> we have a real, real odd behaviour when trying to modify the 
> Expiry-Headers
> .
>
> I did the following:
>
> I created a filter which is called every time my context is accessed. This
> is the definition in web.xml of the application:
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
>      2 <web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
> http://java.s
>      3         <display-name>Dom</display-name>
>      4         <description>
>      5      DOM4
>      6   </description>
>      7         <security-constraint>
>      8                 <web-resource-collection>
>      9                         <web-resource-name>Security
> Constraint</web-resource-name>
>     10                         <url-pattern>/*</url-pattern>
>     11                 </web-resource-collection>
>     12                 <auth-constraint>
>     13                         <role-name>admin</role-name>
>     14                         <role-name>appuser</role-name>
>     15                 </auth-constraint>
>     16         </security-constraint>
>     17         <login-config>
>     18                 <auth-method>FORM</auth-method>
>     19                 <realm-name>SecureRealm</realm-name>
>     20                 <form-login-config>
>     21
> <form-login-page>/jsp/loginForm.html</form-login-page>
>     22
> <form-error-page>/jsp/error.html</form-error-page>
>     23                 </form-login-config>
>     24         </login-config>
>     25         <security-role>
>     26                 <description>AppUser</description>
>     27                          <role-name>appuser</role-name>
>     28         </security-role>
>     29         <filter>
>     30                 <filter-name>HeaderFilter</filter-name>
>     31                 <filter-class>com.cr.manuals.filter.HeaderFilter
> </filter-class>
>     32                 <init-param>
>     33
> <param-name>ADD_TO_CURRENT_MONTH</param-name>
>     34                         <param-value>1</param-value>
>     35                 </init-param>
>     36         </filter>
>     37         <filter-mapping>
>     38                 <filter-name>HeaderFilter</filter-name>
>     39                 <url-pattern>/*</url-pattern>
>     40         </filter-mapping>
>     41 </web-app>
>
> The headerFilter.jar, which contains the class
> com.cr.manuals.filter.HeaderFilter resides in the lib-directory of the
> WEB-INF-directory of my application.
>
> This is the code of the filter:
>
> package com.cr.manuals.filter;
>
> import java.text.SimpleDateFormat;
> import java.util.Calendar;
> import java.util.Date;
> import java.util.Locale;
>
> import javax.servlet.FilterChain;
> import javax.servlet.FilterConfig;
> import javax.servlet.ServletException;
> import javax.servlet.ServletRequest;
> import javax.servlet.ServletResponse;
> import javax.servlet.http.Cookie;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
>
> /**
> * Servlet implementation class for Servlet: HeaderFilter
> *
> */
> public class HeaderFilter implements javax.servlet.Filter {
>
>     private static String PARAM_ADD_TO_CURRENT_MONTH =
> "ADD_TO_CURRENT_MONTH";
>     private FilterConfig filterConfig = null;
>     private int months2Add = 0;
>     /* (non-Java-doc)
>      * @see javax.servlet.http.HttpServlet#HttpServlet()
>     */
>     public HeaderFilter() {
>         super();
>     }
>
>    /**
>    * init() : init() method called when the filter is instantiated.
>    * This filter is instantiated the first time j_security_check is
>    * invoked for the application (When a protected servlet in the
>    * application is accessed).
>    */
>    public void init(FilterConfig aFilterConfig) throws ServletException {
>        filterConfig = aFilterConfig;
>        months2Add =
> Integer.parseInt(filterConfig.getInitParameter(PARAM_ADD_TO_CURRENT_MONTH));
>
>    }
>
>    /**
>    * destroy() : destroy() method called when the filter is taken
>    * out of service.
>    */
>    public void destroy() {
>        filterConfig = null;
>    }
>
>    /**
>    * doFilter() : doFilter() method called before the servlet to
>    * which this filteris mapped is invoked. Since this filter is
>    * mapped to j_security_check,this method is called before
>    * j_security_check action is posted.
>    */
>    public void doFilter(ServletRequest aRequest, ServletResponse 
> aResponse,
>
>                        FilterChain chain) throws java.io.IOException,
> ServletException {
>
>          HttpServletRequest request = (HttpServletRequest)aRequest;
>          HttpServletResponse response = (HttpServletResponse)aResponse;
>          chain.doFilter(request, response);
>          response.setHeader("Expires", createExpiresHeader(months2Add));
>    }
>
>    /**
>     * Create a String in the format EEE, d MMM yyyy HH:mm:ss z"
>     * Example: Fri, 4 Aug 2006 09:07:44 CEST
>     * The value of the init-parama ADD_TO_CURRENT_MONTH is added to the
>     * month-field of the current date
>      * @return
>     */
>    private String createExpiresHeader(int someMonths2Add) {
>        SimpleDateFormat sdf = new SimpleDateFormat("EEE, d MMM yyyy
> HH:mm:ss z", Locale.US);
>        Calendar cal = Calendar.getInstance();
>        cal.add(Calendar.MONTH, someMonths2Add);
>        long millis = cal.getTimeInMillis();
>        Date d = new Date(millis);
>        return sdf.format(d);
>    }
> }
>
> Now what happens?
>
> Everythings is working fine as long as the static content (html, js, xml,
> gif, jpeg), which is served via Tomcat is cached within the browser
> (Firefox, IE 6) and the header is set as expected to an Expiration-Date of
> the actual date plus 1 month (I'm getting a 304 NOT MODIFIED).
>
> However, if the content is not within the browser-cache (I'm getting a 200
> OK), my filter is invoked (I can see this in catalina.out when doing some
> System.out.println()), but the header is set to "Expires: Thu, 01 Jan 1970
> 01:00:00 CET".
>
> Could somebody please tell me what I'm missing here? Is there a secret RFC
> saying that a 200 OK always sets the said Expiration-Date or is this just
> some misbehaviour of Tomcat, maybe even a bug?
>
> I'm realling pulling my hair out to find an answer to this question, and
> without the ability to set the Expiration-date I'm not able to optimize 
> our
> web-app for performance (setting the Expiry- / caching-response-headers).
>
> I know, quite some code above, I apologize for this, however, any 
> suggestion
> are highly, highly appreciated.
>
> Cheers
>
> Greg
>
> PS.: Tomcat 5.0.28
> -- 
> what's puzzlin' you, is the nature of my game
> 




---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message