To use the HTTP response compression functionality, the following preconditions need to be satisfied:

• gzip format compliant Web client
  When the HTTP response compression functionality is enabled, you need to decompress HTTP responses that are compressed in gzip format with the Web client. The Web client, therefore must support the gzip format. If the Web client does not support the gzip format, HTTP responses are not compressed, even if the HTTP response compression functionality is enabled.
  
• HTTP/1.1 compliant Web client
  In HTTP response compression functionality, the value specified in the Accept-Encoding header of the HTTP request determines whether the Web client supports the gzip format. The Web client is therefore required to support HTTP/1.1 as defined in the specifications of the Accept-Encoding header.
  

The memory required for the HTTP response compression functionality is obtained with the following formula:

Memory-required-for-the-HTTP-response-compression-functionality (bytes) = Number-of-concurrent-executions-of-the-HTTP-requests-that-enable-the-HTTP-response-compression-functionality Response-compression-threshold (bytes)

The compression threshold is used for determining whether to compress the HTTP response depending on the size of the HTTP response body. Only when the size of the HTTP response body exceeds the size defined in the compression threshold, the HTTP response will be compressed. Note that the compression threshold is specified for HTTP requests.

Define the compression threshold in the DD (web.xml). When the size of the HTTP response is small, by defining the compression threshold you ensure that the time required for HTTP response compression is not longer than the time required for communication.

Decide an appropriate size for the compression threshold depending on the type of resources you want to compress and the speed of communications line. Hitachi recommends that you acquire the size defined in the compression threshold using the actual measurements and define the appropriate size.

You can specify conditions for enabling the HTTP response compression functionality. The conditions that can be specified are explained below.

• URL pattern of HTTP request
  If the URL of the request to a Web application (in which the HTTP response compression filter is installed) matches with the specified URL pattern, compress the response to that request.
  The following figure shows an example with '*.html' specified as the URL pattern of the HTTP request that executes the compression of HTTP response:
  

  Figure 2-13 Example with '*.html' specified as the UTL pattern of the HTTP request that executes HTTP response compression

  

• Media-Type of HTTP response
  If the value of the Media-Type included in the Content-Type header of the HTTP response matches with the specified value, compress the HTTP response.
  In the case of servlets or JSPs, the value of the Media-Type of HTTP response is set by the setContentType method of a J2EE application. In the case of static contents, the Media-Type is the MIME type associated with the extension.
  The following figure shows an example with 'text/html' specified as the Media-Type of HTTP response that executes the compression of HTTP response:
  

  Figure 2-14 Example with 'text/html' specified as the Media-Type of HTTP response that executes HTTP response compression

  

• Body size of HTTP response
  Set a threshold value to execute the compression of an HTTP response. If the body size exceeds this threshold value, compress the HTTP response.
  The following figure shows an example in which the HTTP response compression functionality is enabled by specifying '200 bytes' as the body size of the HTTP response that executes the compression of HTTP response:
  

  Figure 2-15 Example with '200 bytes' specified as the body size of the HTTP response that executes HTTP response compression

  

Precautions related to the definition of the HTTP response compression filter

When using the HTTP response compression filter, after considering the action of the built-in filter on the HTTP requests and HTTP responses and the restrictions on the order of the filter chain, you need to embed HTTP response compression filter in a Web application. For details on the built-in filter, see 2.9.1 Servlet filter provided by Application Server (built-in filter).

Note that with Servlet 3.0 or later, you can define a filter by using an API and not the web.xml file. However, you cannot use an API to define a built-in filter.

Precautions related to error pages

In the Web applications that use the HTTP response compression functionality, you can customize the error pages by using the following functionality:

• Error page customization with the Web server functionality
• Error page customization based on in-process HTTP server
• Error page customization with the <error-page> tag of web.xml

When using the error page with the <error-page> tag of web.xml, specify the servlet that acquires and uses javax.servlet.ServletOutputStream from the static contents or response in the error page.

In the HTTP response compression functionality, you use javax.servlet.ServletOutputStream acquired from the response object to output the compressed data. Therefore, java.io.PrintWriter cannot be acquired from the response object in the servlet or JSP that generates an error page.