Resource Compression

Version 7 by Ken Fyten
on Nov 21, 2014 11:15.

compared with
Current by Ken Fyten
on Nov 21, 2014 11:16.

These lines were removed. This word was removed.
These lines were added. This word was added.

View page history

There are 1 changes. View first change.

 h2. Overview
 In production systems, it's often desirable to reduce network bandwidth usage by compressing certain types of resources provided from the server. Typically this means that the client indicates via HTTP headers what it will accept. For example:
 When properly configured, the server, for applicable content types, will compress those resources before sending them back to the client.
 As of ICEfaces 3.1, the core framework and components no longer do any compression of HTTP responses by default. Instead, it is recommended that compression be handled either through:
 * configuration of the server platform your application is deployed to
 * configuration of the JSF implementation your application is running on
 h3. Configuring Compression on the Server Platform
 The recommended option is to let your container or web server handle the compression. Nearly every server has a mechanism to provide and configure compression on the responses:
 h4. Tomcat 6 and 7
 In Tomcat, compression is off by default but you can set one or more attributes of the HttpConnector (compression, compressableMimeType, compressionMinSize) to control what type and size of file gets compressed.
 [Tomcat 6 HTTP Connector Configuration|]
 [Tomcat 7 HTTP Connector Configuration|]
 h4. Apache 2.x
 If you are using Apache HTTP server as a front end for your server or cluster, you can configure Apache to do the compression. The mod_deflate module documentation is here:
 [Apache mod_deflate Module Documentation|]
 h4. WebSphere Platforms
 In general, compression in WebSphere is accomplished using IHS (IBM HTTP Server) which is a dedicated web server that sits in front of a WebSphere server or cluster. Since IHS is basically a re-packaged version of Apache, you can use the same mod_deflate module configuration as outlined in the Apache documentation:
 [IHS mod_deflate Module Documentation|]
 h4. WebLogic Platforms
 WebLogic doesn't provide any built-in compression settings. A common solution is to use Apache as noted above or deploy a compression filter as described below.
 h4. Custom Compression Filter
 If the platform you are running on doesn't provide built-in compression or you want more control over the compression yourself, you always have the option to write your own [servlet filter|] which can do the required compression on whichever content types you decide. Or you could download a third-party filter. There is a wealth of information on the web on this topic.
 [Essentials of Filters|]
 h3. Configuring Compression with JSF
 {note:title=No compression in Development mode}In both Mojarra and MyFaces, if the project stage is set to Development, then no compression will occur. However, this only applies to JSF's compression, not compression accomplished through other means.
 {code:xml} <context-param>
 h4. Mojarra
 With Mojarra, compression can be done with a context parameter and specifying the desired content types to compress:
 {code:xml} <context-param>
 The list of types is comma separated and supports the wildcard character ('*'). More information is available by following:
 [Mojarra 2 Release Notes|]
 [JBoss Reference to Mojarra Context Params|]
 h4. MyFaces
 With the MyFaces implementation, configuring compression is a bit more involved than it is with Mojarra. You need to add the MyFaces Commons library:
 [MyFaces Commons Resource Handler|]
 and then set one or more context parameters as outlined in the documentation:
 [MyFaces Resource Handler Parameters|]
 h4. History of Resource Compression in ICEfaces
 The strategy for compressing resources in ICEfaces has changed from previous versions. In ICEfaces 1.x, we typically compressed nearly all of the resources we served ourselves, with the behaviour being modified though the use of a context parameter (see [compressResources]):
 {code:xml} <context-param>
  With ICEfaces 2.x and above, the context parameter remains, although changed to reflect the packaging changes in the product:
 {code:xml} <context-param>
 However, with with ICEfaces 2.x and above, the compression only applies to a subset of the resources served. This includes the compat resources served via CompatResourceServlet as well as any resources added to the ResourceRegistry via methods like addSessionResource(Resource resource). This is typically done in certain components (File Entry, Data Exporter) and can also be used by application code.
 There are a couple of different issues with this approach. One is that it's inconsistent. Some resources, as noted above, are compressed by ICEfaces and some (like jsf.js or bridge.js) are not compressed by ICEfaces at all. Another potential problem is that, since it's on by default and only some resources are compressed, it's possible that those resources could also be compressed by handlers other than ICEfaces. The portlet container Liferay is an example where certain resources are compressed by default. Since the compression handling overlaps it can lead to double-compression (both Liferay and ICEfaces compressing the same file) and double-compressed files are not handled well by most browsers.
 Going forward, our recommendation is to rely on the tools provided by your server platform or the features provided in your JSF implementation to handle your compression requirements so that the behaviour is consistent and predictable.

© Copyright 2018 ICEsoft Technologies Canada Corp.