= Proposal number : ? Proposal title : GZIP content compression filter to reduce network traffic =

|| '''Date''' || 2008/07/21 ||
|| '''Contact(s)''' || Simon Pigot ||
|| '''Last edited''' || [[Timestamp]] ||
|| '''Status''' || draft, being discussed, complete ||
|| '''Assigned to release''' || 2.3.0 ||
|| '''Resources''' || Test implementation is complete ||

== Overview ==

Compression reduces the size of HTTP responses and compressed content is now understood by many browsers (its been around since HTTP/1.1) including firefox 1+, IE5+, etc. This can speed up the time it takes for pages with lots of content to refresh and draw. Most developers don't realize this because they usually test using localhost. Responses sent by GN will only grow larger as both the metadata standards and the content they contain grow richer and the user interface becomes more complex (read more JavaScript). As an example, a large iso19139 metadata record with a few sizeable select/pulldown lists took half the time it used to take to render when the compression filter was added.

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.

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.

=== Proposal Type ===
 * '''Type''': Servlet configuration, configuration change
 * '''App''': GeoNetwork and Intermap
 * '''Module''': servlet configuration (web.xml files)

=== Links ===
 * '''Documents''': [http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html Two servlet filters every web app should have] and [http://www.http-compression.com/ for a discussion of http compression and browser support]

=== Voting History ===
 * Not voted on yet.

----

== Motivations ==
Compression of HTTP responses from GeoNetwork will speed up page refreshes and reduce the network footprint required to run GeoNetwork - see overview above.

== Proposal ==

Insert compression filter in servlet path.

This involves modifications to web/geonetwork/WEB-INF/web.xml and web/geonetwork/WEB-INF/web.xml as follows:

{{{
  <filter>
    <filter-name>GZIPCompressor</filter-name>
    <filter-class>com.jspbook.GZIPFilter</filter-class>
  </filter>

  <filter-mapping>
    <filter-name>GZIPCompressor</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>

}}}

and finally the inclusion of a new jar: GZIPFilter.jar in web/geonetwork/WEB-INF/lib and web/intermap/WEB-INF/lib.

=== 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.

== Risks ==

Unknown.

== Participants ==
 * As above