CSP Gateway Configuration Guide - InterSystems Documentation

intersystems.com

CSP Gateway Configuration Guide - InterSystems Documentation

Compressing the Response to Requests for CSP Forms (GZIP/ZLIB)

shareable image for OpenVMS. The library libz.so (or libz.sl) is usually pre-installed on all Linux systems (it is usually

installed in /usr/lib/ or /usr/local/lib).

The Gateway dynamically links to the ZLIB library when response compression is requested for the first time. Thereafter

the ZLIB library remains loaded until the Gateway is closed down.

For Windows, the ZLIB library should be installed in the Windows System32 directory:

C:\WINDOWS\SYSTEM32\ZLIB.DLL

It should be noted that in the latest distributions, the library is named as ZLIB1.dll. This must be renamed to ZLIB.DLL in

order for the Gateway to find it.

For UNIX® systems, the library (libz.so or libz.sl) is usually installed in one of the following locations:

• /usr/lib/

• /usr/local/lib/

If the 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:

CSP Gateway Initialization

The ZLIB library is loaded - Version 1.2.3.

(This library is used for the optional GZIP compression facility)

If the Gateway cannot find or link to the ZLIB library, it operates as before (pages are returned without being compressed).

A statement of failure is written to the Event Log.

2.6.2 Using the GZIP/ZLIB Library

The Gateway implements two modes of operation (1 and 2) for compressing the response data using the ZLIB library:

1. In this mode, the Gateway streams all data received from Caché into the compressor. When all the data has been processed,

the compressor streams the compressed data back to the 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.

2. In this mode, the Gateway streams all data received from Caché into the compressor. On each and every call, the

compressor makes as much compressed data as it can available to the 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 CSP applications where it’s usually not possible to know, in advance, how much data a CSP

response contains.

If (and only if) the Gateway is able to successfully compress the data stream returned from Caché, 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: Fri, 15 Aug 2003 10:05:18 GMT

EXPIRES: Thu, 29 Oct 1998 17:04:19 GMT PRAGMA: no-cache Content-Encoding: gzip

Before attempting to compress response data, the Gateway always checks the value of the Accept-Encoding HTTP

request header (the HTTP_ACCEPT_ENCODING CGI environment variable). The Gateway only compresses a response

if the client has indicated that it is capable of dealing with compressed content.

For example:

CSP Gateway Configuration Guide 43

More magazines by this user
Similar magazines