CSP Gateway Configuration Guide - InterSystems Documentation

More documents

Recommendations

Info

CSP Gateway Operation and Configuration Environment Variable HTTP_SOAPACTION HTTP_USER_AGENT HTTPS PATH_TRANSLATED REMOTE_ADDR REMOTE_HOST REMOTE_IDENT REMOTE_USER REQUEST_METHOD SERVER_NAME SERVER_PORT SERVER_PORT_SECURE SERVER_PROTOCOL SERVER_SOFTWARE Value SOAPAction HTTP request header field can be used to indicate the intent of the SOAP HTTP request.The value is a URI identifying the intent. SOAP places no restrictions on the format or specificity of the URI or that it is resolvable. An HTTP client MUST use this header field when issuing a SOAP HTTP Request. Browser the client is using to send the request. General format: software/version library/version. This is set to on if the script is being called through a secure server (that is, using SSL). Translated version of PATH_INFO, in which any virtual-to-physical mapping is applied to the path. IP address of the remote host making the request. Hostname making the request. If the server does not have this information, it should set REMOTE_ADDR and leave this parameter unset. If the HTTP server supports RFC 931 identification, then this variable is set to the remote user name retrieved from the server. Name of the user as it is derived from the authorization header sent by the client Method with which the request was made. For HTTP, this is GET, HEAD, POST, and so on. The server's hostname, DNS alias, or IP address as it would appear in self-referencing URLs. Port number to which the request was sent. For example: 80 Set to either 0 or 1. If the request is being handled on the Web server’s secure port, then it is set to 1. Otherwise, it is set to 0. Name and revision of the information protocol that the request came in with. Format: protocol/revision Name and version of the Web server software responding to the request. Format: name/version. 2.4 HTTP Response Headers CSP and CSP-based applications usually assume the responsibility for formulating a full HTTP response header. For performance reasons the Gateway traditionally 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 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 CSP. For example, 32 CSP Gateway Configuration Guide
HTTP Response Headers 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 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: Do %response.SetHeader("CSP-nph", "false") Quit 1 When set to false, (the default setting for the 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 CSP 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 OR: Server: Sun-ONE-Web-Server/6.1 Note that this facility only applies to the use of Gateway implementations that work directly to Web server APIs. In other words: everything other than CGI. If the 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: Example: Status: 200 OK For nonparsed headers, format the HTTP status line as follows: HTTP/1.1 Example: HTTP/1.1 200 OK The CGI modules supplied with the 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 the Adding an Application Path section CSP Gateway Configuration Guide 33
Page 1 and 2: CSP Gateway Configuration Guide Ver
Page 3 and 4: Table of Contents About this Book .
Page 5: 5 Web Servers for UNIX®, Linux, an
Page 9 and 10: 1 Introduction to the CSP Gateway T
Page 11 and 12: Using the Network Service Daemon (N
Page 13 and 14: Minimal Apache Web Server or Privat
Page 15 and 16: 2 CSP Gateway Operation and Configu
Page 17 and 18: CSP Web Gateway Management Page The
Page 19 and 20: CSP Web Gateway Management Page 2.1
Page 21 and 22: CSP Web Gateway Management Page Use
Page 25 and 26: CSP Web Gateway Management Page Log
Page 29 and 30: CSP Web Gateway Management Page 2.1
Page 31 and 32: CSP Web Gateway Management Page Par
Page 33 and 34: CSP Gateway and Security 4. Click S
Page 35 and 36: CSP Gateway and Security Windows Pa
Page 37: CGI Environment Variables The clien
Page 41 and 42: Compressing the Response to Request
Page 43 and 44: Compressing the Response to Request
Page 45 and 46: CSP Page Output Caching 2.7.1 %resp
Page 47 and 48: CSP with Microsoft Active Server Pa
Page 49 and 50: Registering Additional File Types w
Page 51 and 52: Registering Additional File Types w
Page 53 and 54: Implementing HTTP authentication fo
Page 55: Implementing HTTP authentication fo
Page 58 and 59: Using Caché Server Pages with a Re
Page 65 and 66: 4 Web Servers for Microsoft Windows
Page 67 and 68: Microsoft Internet Information Serv
Page 89 and 90:
Microsoft Internet Information Serv
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Apache Servers This, for example, i
Page 99 and 100:
Apache Servers 4.3.2 Option 1: Apac
Page 101 and 102:
Apache Servers Duplicate this confi
Page 103 and 104:
Apache Servers 4.3.4.1 Operating an
Page 105 and 106:
Apache Servers copy c:\MyCache\csp\
Page 107 and 108:
Operating the Network Service Daemo
Page 109 and 110:
5 Web Servers for UNIX®, Linux, an
Page 111 and 112:
Sun Web Servers 3. HyperEvents Comp
Page 113 and 114:
Apache Servers Locate the block of
Page 115 and 116:
Apache Servers /usr/CSPGateway/bin
Page 117 and 118:
Apache Servers To be consistent wit
Page 119 and 120:
Apache Servers SetHandler csp-hand
Page 121 and 122:
Apache Servers ScriptAliasMatch /*\
Page 123 and 124:
Apache Servers 5.2.4.2 Check the Ap
Page 125 and 126:
Apache Servers The Web server confi
Page 127 and 128:
Page 129:
Page 132 and 133:
Web Servers for Hewlett-Packard (HP
Page 134 and 135:
Page 136 and 137:
show all

CSP Gateway Configuration Guide - InterSystems Documentation

Create successful ePaper yourself

Delete template?

Save as template?