Women in Technology

Article:		Two Servlet Filters Every Web Application Should Have
Subject:		MAJOR bug in compression filter for non-US webapps
Date:		2003-12-01 16:17:17
From:		knuterik
I started testing this compression setup after reading this article, and found the concept promising enough to start testing compression using the jspbook.jar in one of my webapps. For a while everything seemed just OK (tested using english locale). I decided to let this filter be part of my 'standard web-app setup', and set off developing on my webapp. After a week or so, the shit really hit the fan ;-) All the localised pages in my application was starting to look really funny. Where the norwegian characters was to have been, I instead got some funny (escaped?) characters instead. This also made some of my submit-buttons stop working (the ones with localised text on them). I really had a hard time figuring out what the h... had happened, since this particular change was way back in time (a week ;-). But after i a while, I figured out that the gzip compression filter was to blame. - It actually CHANGES the character encoding of the output!!!!!!!!! So, all my localised resources in my JSP pages suddenly went mad.

Showing messages 1 through 8 of 8.

• MAJOR bug in compression filter for non-US webapps
  2003-12-01 18:50:58  jfalkner [View]
  
  
  I've changed the filter to reuse the character encoding set by the previous response. This should fix the problem you described, but please let me know if you are still having troubles with the code.
  
  You can snag a copy of the updated code at http://www.jspbook.com/jspbook.jar.
• MAJOR bug in compression filter for non-US webapps
  2004-01-07 10:03:20  anonymous2 [View]
  
  
  I just installed the latest version of this code to get compression. However it seems that there is still an issue with i18n.
  Before putting the filter, Mozilla displayed my app in english and IE in french.
  
  With compression, both browsers display my messages in english... Is this another attribute that should be captured and transfered but is not?
  
  D. de Waleffe
• MAJOR bug in compression filter for non-US webapps
  2004-01-07 18:54:34  jfalkner [View]
  
  
  How are you doing i18n detection in your web app? If it isn't using something the cache filter relies on (i.e. standard i18n headers) it won't work with the cache filter. However, it should be a relatively easy fix to modify the cache filter to work with any i18n scheme you are using -- take advantage of the source-code!
• MAJOR bug in compression filter for non-US webapps
  2004-01-08 02:00:40  anonymous2 [View]
  
  
  I rely on struts to do this....
  
  However I just observed that the behaviour I mentionned depends on the server I'am using...
  Using one instance (the local tomcat), I get Mozilla-en, IE-fr. Using the other instance on another machine I have (same code) Mozilla-en,IE-en...
  
  So it must come from something else than the compression code... Sorry for this thought...
  D. de Waleffe
• Source code?
  2003-12-02 02:43:17  knuterik [View]
  
  
  Have you also posted the source code anywhere?
  
  It would be nice to see exactly what you did and how.
  Also, I would like to change the output (System.out.println....) to instead use a logging framework etc.
  - Then, I would like to try these filters again in my webapps ;-)
• Source code?
  2003-12-03 17:01:57  jfalkner [View]
  
  
  Oops, about using a logging framework. That is an excellent idea. In the book this topic is explained at length, and examples are provided for using the java.util.logging API with a web application. The only reason these examples don't use the java.util.logging package is because the filters are meant to be as simple as possible -- the focus is on understanding caching and compression, not logging ;)
• Source code?
  2003-12-03 16:58:41  jfalkner [View]
  
  
  Yes, the source-code for my entire book and the entire book support website is available at http://www.jspbook.com. You can always grab a copy of the current source-code by browsing directly to http://www.jspbook.com/jspbook.war.
  
  The source-code is with the rest of the book's source-code. You'll have to browse to the WEB-INF/classes/com/jspbook directory to find the ".java" files you would be interested in.

• Cause: hardcoded charset encoding
  2003-12-01 16:28:22  knuterik [View]
  
  
  In GZIPResponseWrapper.java:
  
  writer = new PrintWriter(
  new OutputStreamWriter(stream, "UTF-8"));
  
  
  Should maybe instead check for current encoding of output stream, and then continue using it?