Changes between Version 7 and Version 8 of GZIPFilter

Timestamp:

Mar 23, 2009, 5:29:00 AM (15 years ago)

Author:

simonp

Comment:

--

GZIPFilter

@@ -31 +31 @@
 == Proposal ==
 
-A GZIP compression filter has been written for general use by the people at jspbook.com - [http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html Two servlet filters every web app should have] - this filter has been adapted for use in GeoNetwork and some issues that caused trouble in Internet Exploder has been fixed. The filter will only be applied to requests that can accept gzip compression and to requests that are not asking for type image/* as images are almost always compressed anyway.
+A GZIP compression filter has been written for general use by the people at jspbook.com - [http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html Two servlet filters every web app should have] - this filter has been adapted for use in GeoNetwork and some issues that caused trouble in Internet Exploder has been fixed. The filter will only be applied to requests that can accept gzip compression and to requests that are not asking for an image (trapped using suffixes) or for a resource such as a thumbnail or download file as all of these are almost always compressed anyway.
 
-One other function that may prove to be useful has been added to the filter. This function sets the expiry date on certain types of content (javascript, css, locale images) into the far future. The idea here is that this content will not be downloaded each time a user returns to a previously loaded page - instead this content will be found either in the web browser or proxy cache. The down side with this feature (apart from whether it really saves all that much anyway) is that the filenames of the static content need to change when a new version of GeoNetwork is released to avoid stale static content being retrieved from the cache. This is not implemented in GeoNetwork and whether it is worth it will depend upon further testing of the worth of this feature.
+One other function that may prove to be useful has been added to the filter. This function sets the expiry date on certain types of content (javascript, css, locale images) into the far future. The idea here is that this content will not be downloaded each time a user returns to a previously loaded page - instead this content will be found either in the web browser or proxy cache. The down side with this feature (apart from whether it really saves all that much anyway) is that the URLs of the static content need to change (eg. by adding ?version=whatever to javascript tags) when a new version of GeoNetwork is released to avoid stale static content being retrieved from the cache. This is not implemented in GeoNetwork and whether it is worth it will depend upon further testing of the worth of this feature.
 
 Steps needed to insert compression filter in servlet path. This involves modifications to web/geonetwork/WEB-INF/web.xml and web/intermap/WEB-INF/web.xml as follows:
@@ -64 +64 @@
 === Backwards Compatibility Issues ===
 
-Some allusion is made in various places on the net to early versions of browsers not properly supporting compressed content - see [http://www.http-compression.com/ for a discussion of http compression and browser support]. The short answer is that the browsers we want to support (IE 7+, Firefox 2+ and others) all support compressed content without issues BUT there have been reports of gzip compression causing confusion on Windows Vista. If Vista is an issue then perhaps this Vista clients can be trapped by examining http headers and switching off gzip compression for such requests.
+Some allusion is made in various places on the net to early versions of browsers not properly supporting compressed content - see [http://www.http-compression.com/ for a discussion of http compression and browser support]. The short answer is that the browsers we want to support (IE 7+, Firefox 2+ and others) all support compressed content without issues BUT there have been reports of gzip compression causing confusion on Windows Vista. If Vista is an issue then perhaps Vista clients can be trapped by examining http headers and switching off gzip compression for such requests or alternatively sites can disable the filter altogether by commenting it out in the web.xml file.
 
 == Risks ==