Skip to main content

Define an Application Access Profile for Your Web Application Path

This page describes how to configure application access profiles for the InterSystems Web Gateway. Application access profiles determine where the Web Gateway routes requests for a certain web application path. An application access profile can specify the server access profile for one target application server, or it can specify a series of server access profiles as part of a load-balancing or failover scheme.

To route a request for a web application, you must configure an application access profile for a path which contains the request’s URL path. For a given request, it may be possible to route requests to a given web application in multiple ways. See this page for guidance.

For these and other configuration tasks, use the Web Gateway management pages or Web Gateway Registry methods. The Web Gateway maintains configuration information in the CSP.ini file.


Except in containerized deployments where it may be necessary to edit the CSP.ini file directly, InterSystems recommends restricting access to the CSP.ini file and performing all Web Gateway configuration using the Web Gateway management pages.

Add an Application Access Profile

To specify where and how the Web Gateway should route requests for a certain application path, define an application access profile for that path within the Web Gateway configuration. To do so:

  1. On the Web Gateway management pages main menu, select Application Access.

  2. Select Add Application. Note that many parameters have default settings.

  3. In the Application Path text box enter a unique path for the application. This path is the path which appears in the application URLs.

  4. Enter the other configuration path and server parameters (described in the tables below) for this application.

  5. When you have finished, select Save Configuration. Changes you make to the application configuration take effect as new user sessions are created for that application path. Existing users are unaffected.

Application Access Profile Configuration Parameters

The set of base parameters are as follows:

Parameter Function
Service Status Enable and disable access to an application via the application path (default is Enabled).
Web Server Physical Path Path to the corresponding directory on the web server. This setting is particularly important for Microsoft IIS systems where each path configured must be set up as a virtual directory under the web server configuration. Each virtual directory defined within IIS must have a physical path associated with it. The purpose of this additional configuration procedure for IIS is to allow the paths used by InterSystems IRIS to be defined with execute permissions. The default is for execute permissions to be denied.
Extra CGI Environment Variables Comma-separated list of additional CGI environment variables to be returned to the InterSystems IRIS environment with each and every request. The commonly-used CGI environment variables are automatically sent with each request. Enter the wildcard character (*) to instruct the Web Gateway to send all environment variables supplied by the web server to the InterSystems IRIS server with each request.
Process with this class Process files in this path with the specified class. This allows you to build your own request handlers in CSP.
GZIP Compression Enable or disable GZIP compression for all CSP pages returned in this path (default is Disabled).
GZIP Minimum File Size Minimum response size, in bytes, for which GZIP compression is invoked. Default is 500 bytes.
GZIP Exclude File Types

This is a list of file types to be excluded from GZIP compression. Files to be excluded 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.

Response Size Notification

This parameter provides configurable control over the method used by the Web Gateway to notify clients of the amount of data contained in each response.

Web clients typically require some form of response size notification if HTTP KeepAlive connectivity is used. Under these circumstances, the Web Gateway defaults to using chunked transfer encoding, provided HTTP v1.1 is in use. If an earlier HTTP protocol is in force it buffers the response data received from InterSystems IRIS and generate a content-length header instead. Also, in cases where the entire response fits into one output buffer a content-length header is generated instead of using chunked transfer.

There are scenarios in which it is desirable to instruct the Web Gateway to specifically use one method or the other. For example, in cases where HTTP v1.1 is used but some intermediary (such as a proxy) is unable to properly support chunked transfer. Also, while not sending any form of size notification (such as, where the close connection event is used as the response terminator) should be supported by all web clients, it is nevertheless recommended as 'good practice' that all responses should be accompanied by some form of size notification. Indeed, some clients require this.

The following options are provided:

  • Chunked Transfer Encoding and Content Length (the default)

  • Chunked Transfer Encoding

  • Content Length

This parameter is supplemented with a check box to instruct the Web Gateway to always generate a size notification for all requests regardless of whether or not KeepAlive is used.

There is a 500 kilobyte limit on the size of HTTP responses that specify a content-length header, as opposed to chunked responses. If you exceed this limit, a warning message appears in the CSP log:

WARNING: Unable to generate a 'Content-Length' header directive for this oversize response (Current size: size; Maximum buffer size allowed: 500000)

KeepAlive Enable or disable HTTP KeepAlive connectivity for this path. Default is No Action in which case the KeepAlive status is determined by the HTTP response headers for each request.
Non-Parsed Headers Enable or disable Non-Parsed Headers protocol for this path. Default is Enabled in which case HTTP response headers are streamed directly back to the client. If this property is disabled, the response headers are submitted back to the hosting web server. This gives the web server the opportunity to parse the headers and invoke any output filters that may be indicated. For example, the Apache Group’s mod_deflate facility. Note that for the Apache web server, if keep-alive is enabled, then the response headers are submitted back to Apache regardless of the Non-Parsed Headers setting.

Server Parameters

You can define a list of InterSystems IRIS servers to use for an application and the purpose for which they are to be used.

Parameter Function
Use Alternate Servers For

The first server listed, Server 0, is the default InterSystems IRIS server. It is used first. Other listed servers can be used for load balancing or failover, depending on the option checked.

  • Fail-Over If the first server fails (becomes unavailable), use an alternative.

  • Load-Balancing and Fail-Over . If the first server fails, use a server that is configured as either failover or load-balancing.

Server #: List of servers. The configuration screen initially shows only three server slots, but additional slots appear that enable you to define any number of alternative servers. Each server can be checked as Enabled or Disabled. Default is always Enabled. See Load Balancing and Failover Between Multiple InterSystems IRIS Server Instances for more information.

Copy an Application Access Profile

You can quickly configure a new application path by copying the application access profile for an existing path and editing it.


This feature is also useful for fine-tuning a configuration. By creating a second (temporary) application access profile for an application path, you can test parameter changes without worrying about losing the original configuration.

To copy an existing application access profile:

  1. From the Web Gateway management pages main menu, select Application Access.

  2. On the Application Access screen, select an existing application path.

  3. Select Copy Application.

  4. Select Submit.

  5. In the Application Path text box, enter a new and unique application path.

  6. Select Save Configuration. The new application configuration takes effect as new user sessions are created for the new application path. Existing users are unaffected.

Disable Access via an Application Path

Use this facility to prevent users accessing a configured application through this Web Gateway installation.

To disable access via an application path:

  1. From the Web Gateway management pages main menu, select Application Access.

  2. At the Application Access screen, select an application path.

  3. Select Edit Application.

  4. Select Submit. The configuration screen for the application path appears.

  5. For the Application Status parameter, select Disabled.

  6. Select Save Configuration.

To re-enable access, repeat the procedure and select Enabled at Step 5.

Delete an Application Access Profile

To delete an existing application access profile:

  1. From the Web Gateway management pages main menu, select Application Access.

  2. At the Application Access screen, select an application path.

  3. Select the Delete Application option.

  4. Select Submit.

  5. Force a restart of all the applications by restarting the web server.

FeedbackOpens in a new tab