• Bug
  • Status: Closed
  • Resolution: Fixed
  • drb
  • Reporter: sourceforgetracker
  • September 21, 2009
  • 0
  • Watchers: 0
  • September 22, 2009
  • September 22, 2009

Description

Hello,

While using the GZipFilter in v1.3.0 (I think it also applies to v1.4.0), I think the response wrapper setHeader should not by default add the header but rather override the header if it exists, I believe the std indicates as such.

If the header already exists and would like to change the value of it, like the Content-Disposition header, the setHeader adds a new entry for the header rather than change the value of it.

Thanks for your consideretion.

Nuri Sourceforge Ticket ID: 1890915 - Opened By: nobody - 11 Feb 2008 05:53 UTC

Comments

Sourceforge Tracker 2009-09-21

Logged In: YES user_id=693320 Originator: NO

Nuri

I cannot think why I did that originally. We have been using this for four years!

Have made the change.

/**
 * Set the headers in the response object, excluding the Gzip header
 *
 * @param pageInfo
 * @param requestAcceptsGzipEncoding
 * @param response
 */
protected void setHeaders(final PageInfo pageInfo,
                          boolean requestAcceptsGzipEncoding,
                          final HttpServletResponse response) {

    final Collection headers = pageInfo.getHeaders();
    final int header = 0;
    final int value = 1;

    for (Iterator iterator = headers.iterator(); iterator.hasNext();) {
        final String[] headerPair = (String[]) iterator.next();
        response.setHeader(headerPair[header], headerPair[value]);
    }
}

All the tests seem to pass against Orion and Tomcat, so I guess it is ok.

This is in trunk and will be in ehcache 1.5 Thanks for your patch. Comment by: gregluck - 31 Mar 2008 07:21 UTC

Fiona OShea 2009-09-22

Re-opening so that I can properly close out these issues and have correct Resolution status in Jira