Compressing the Response to Requests for CSP Forms (GZIP/ZLIB)
Compressing the response generated by the CSP engine before dispatching it to the client is advantageous because it can dramatically reduce the network bandwidth required to transport the response to the client. From the client’s perspective the performance of the application is improved. This is particularly true for clients accessing the application through mobile devices over slower telecommunications networks. There is, of course, a cost in terms of the web server host’s CPU time that’s required to actually compress the data but this is a small price to pay for the advantages.
The advantage of serving compressed response data is particularly marked for CSP pages for which large volumes of response data are generated.
There are two methods for implementing GZIP in a web server environment.
Using the Web Gateway’s own interface to the GZIP library described here.
Using a GZIP output filter as an add-on to the hosting web server.
Most web servers offer add-on facilities for compressing data. Windows/IIS offers a gzip filter (implemented as an ISAPI filter). The Apache Group offer a compression filter implemented as an add-on module (mod_deflate.c – which, rather confusingly, implements gzip compression not deflate). There is also a third-party module for Apache called mod_gzip.c. There are a number of third-party GZIP products available as add-ons for most web servers.
The advantages of implementing a compression solution directly in the Web Gateway are as follows:
Ease of setup and configuration.
Greater flexibility in controlling which CSP files are to be compressed.
Compression tends to work better if the data is submitted to the compressor functions in large buffers. The Web Gateway receives the response content from InterSystems IRIS in fairly large chunks; therefore the performance of the compression and the degree of compression achieved are good.
It has been discovered that if Chunked Transfer Encoding is enabled at the Web Gateway level and if the Apache mod_deflate output filter is enabled for the same resources, then browsers are occasionally unable to display the response content.
The Web Gateway makes use of the freely available GZIP (or zlib) library for implementing data compression. The compression algorithm used is described in RFCs (Request for Comments) 1950 to 1952.
The GZIP/ZLIB Library
The GZIP/ZLIB library was developed by Jean-loup Gailly and Mark Adler (Copyright (C) 1995-2009). A pre-built version of this library (version 1.2.11) is provided with InterSystems IRIS distributions on Windows. On UNIX systems, the Web Gateway uses the OS-supplied build of ZLIB.
The Web Gateway dynamically links to the ZLIB library when response compression is requested for the first time. Thereafter the ZLIB library remains loaded until the Web Gateway is closed down.
If the Web Gateway is able to load the ZLIB library on demand and identify all the required functions, the following initialization message is written to the Event Log:
Web Gateway Initialization The ZLIB library is loaded - Version 1.2.11. (This library is used for the optional GZIP compression facility)
If the Web Gateway cannot find or link to the ZLIB library, it operates as before and pages are returned without being compressed. A statement of failure is written to the Event Log.
Using the GZIP/ZLIB Library
The Web Gateway implements two modes of operation (1 and 2) for compressing the response data using the ZLIB library:
In this mode, the Web Gateway streams all data received from InterSystems IRIS into the compressor. When all the data has been processed, the compressor streams the compressed data back to the Web Gateway at which point it is forwarded on to the client.
This mode offers the best possible compression at the expense of slightly higher latency. Of course, the latency is more pronounced for larger forms.
In this mode, the Web Gateway streams all data received from InterSystems IRIS into the compressor. On each and every call, the compressor makes as much compressed data as it can available to the Web Gateway at which point it is forwarded on to the client.
This mode offers the lowest possible latency at the expense of slightly reduced level of compression. Of course, the reduction in the degree of compression achieved is more pronounced for larger forms. Generally speaking, mode 2 is more appropriate for web applications where it is usually not possible to know, in advance, how much data a response contains.
If (and only if) the Web Gateway is able to successfully compress the data stream returned from InterSystems IRIS, it modifies the HTTP response headers to include the appropriate Content-Encoding directive. For example:
HTTP/1.1 200 OK Content-Type: text/html; charset=ISO-8859-1 Set-Cookie: CSPSESSIONID=000000000002119qMwh3003228403243; path=/csp/samples/; Cache-Control: no-cache Connection: Close Date: <date and time> Expires: <date and ttime> Pragma: no-cache Content-Encoding: gzip
Before attempting to compress response data, the Web Gateway always checks the value of the Accept-Encoding HTTP request header (the HTTP_ACCEPT_ENCODING CGI environment variable). The Web Gateway only compresses a response if the client has indicated that it is capable of dealing with compressed content.
Accept-Encoding: gzip, deflate
There are several methods for specifying that a CSP response should be compressed. These are discussed in the following sections.
Specifying Compression for Individual Pages
Within web applications, the %response object contains a property called GzipOutput. If this property is set to true (or the mode required) the Web Gateway attempts to compress the response.
<script language=objectscript method=OnPreHTTP arguments="" returntype=%Boolean> Set %response.GzipOutput = 2 Quit 1 </script>
Compression can also be specified on a per-page basis by adding the CSP-gzip directive to the HTTP response headers. This must, of course, be done in the OnPreHTTP method. For example:
<script language=objectscript method=OnPreHTTP arguments="" returntype=%Boolean> Do %response.SetHeader("CSP-gzip", "2") Quit 1 </script>
The CSP-gzip header directive should be set to the compression mode required (1 or 2).
Specifying Compression for All Pages within an Application Path
Compression can be specified on a per-application path basis. This, incidentally, is the most common method for indicating that compression should be used when using a web server output filter (such as mod_deflate).
Use the following configuration parameters in the Web Gateway Application Access section:
|GZIP Compression||If Enabled, all CSP output for that path is compressed. Default is Enabled.|
|GZIP Minimum File Size||Controls the minimum response size in bytes for which compression is activated. If left empty, then all responses for which GZIP is enabled are compressed.|
|GZIP Exclude File Types||
List of file types to be excluded from GZIP compression. Files can be listed by MIME type (such as image/jpeg) or by common extension (such as jpeg).
By default, these common (natively compressed) image files are excluded:GZIP Exclude File Types: jpeg gif ico png gz zip mp3 mp4 tiff.
Separate additional types or extensions with a space.
Log level V3 instructs the Web Gateway to record the degree of compression achieved for all responses that were successfully compressed. The size of the compressed data and the original uncompressed data stream is recorded.
GZIP Compression for /csp/samples/inspector.csp GZIP Mode=1; Uncompressed Content Size=19042; Compressed Content Size=2499 (13 percent)