HTTP Response Headers Returned by the Web Gateway
Web applications in InterSystems IRIS® (including REST-based applications) usually assume the responsibility for formulating a full HTTP response header. For performance reasons, the Web Gateway by default streams the response headers, together with the following content, directly to the client via the web server. This mode of operation is known as the non-parsed header (NPH) approach. The Web Gateway does not grant the hosting web server any control over the response headers by passing them back through the dedicated API functions provided by the server. It is assumed that it is the client that needs to read and interpret the response header directives rather than the web server.
However, this assumption breaks down in cases where it necessary for the web server to interpret the response headers in order to invoke further web server-based functionality implied in the header directives generated by the CSP engine) For example, by invoking output filters to further process the response (compression and encryption utilities etc.). Such output filters are usually found not to work for CSP content returned according to the nonparsed header mode of operation.
A facility exists to instruct the Web Gateway to explicitly pass the response headers through the hosting web server instead of streaming them directly to the client.
To use this facility, set the following CSP header directive: CSP-nph: false
This directive must be set in the OnPreHTTP() method. For example:
<script language=objectscript method=OnPreHTTP arguments=""
returntype=%Boolean>
Do %response.SetHeader("CSP-nph", "false")
Quit 1 </script>
When set to false, (the default setting for the Web Gateway is true), the CSP-nph directive ensures that the hosting web server is properly notified as to the nature of the response through the response headers returned from the CSP engine. As a result, any further processing can be performed as necessary. This is parsed header mode.
When the Web Gateway is operating in parsed header mode, the hosting web server interprets the response headers and perhaps add header directives of its own. At the very least it adds a Server header to the response. For example:
Server: Apache/2.0.48 (Win32)
OR:
Server: Microsoft-IIS/5.1
Note that this facility only applies to the use of Web Gateway implementations that work directly to web server APIs. In other words: everything other than CGI.
If the Web Gateway CGI modules are used and this facility is required then you must configure the web server to use the non-NPH versions of the CSP CGI modules. For example, use CSPcgi instead of nph-CSPcgi. The nph- prefix used in the name of a CGI module is the standard way of informing the web server that it is not required to read and interpret the response headers returned by the module: in other words operate in non parsed header mode.
The essential difference between the parsed and non-parsed versions of these modules lies in the way the HTTP response status line is formulated. This is the first line in the header block.
For parsed headers, format the HTTP status line as follows:
Status: <status_code>
Example:
Status: 200 OK
For nonparsed headers, format the HTTP status line as follows:
HTTP/1.1<status_code>
Example:
HTTP/1.1 200 OK
The CGI modules supplied with the Web Gateway automatically handle these differences internally. The CSP engine always return a standard HTTP header block (2).
See also the Non-parsed Headers parameter in Adding an Application Path.