- magnus.conf
| # ****** Weblogic Proxy plug-in ****** Init fn="load-modules" funcs="wl_proxy,wl_init" shlib="E:/Sun/WebServer6.1/plugins/weblogic/proxy61.dll" Init fn="wl_init" # ****** End Weblogic plug-in ***** |
- obj.conf:
Configuration of the obj.conf varies depending on the intended use. See the Java System Web Server documentation for use and syntax of the obj.conf.
Example 1
This configuration will proxy the URI “/example” if it does not exist locally. A local copy of “/example” is preferred to a remote copy:
| <Object name="default"> # Assign the URI "/example" (and any more specific URIs; # /example/foo.html, /example/qwe.jsp, etc) the object name # "server.example.com" NameTrans fn="assign-name" from="/example(|/*)" name="server.example.com" ... </Object> # Execute these instructions for any resource with the assigned name # "server.example.com" <Object name="server.example.com"> # Check to see if a local copy of the requested resource exists. Only # proxy the request if there is not a local copy. ObjectType fn="check-passthrough" Sun Microsystems, 11 Configuring the Reverse Proxy Plug-in , Inc. type="magnus-internal/passthrough" # Proxy the requested resource to the URL # "http://server.example.com:8080" only if the "type" has been set to # "magnus-internal-passthrough" Service type="magnus-internal/passthrough" fn="service-passthrough" servers="http://server.example.com:8080" </Object> |
Example 2
This configuration will proxy all requests for the URI “/app” without first checking for a local version. The reverse proxy plug-in provides its own credentials via Basic-Auth to the origin server.
| <Object name="default"> # Assign the URI "/app" (and any more specific URIs; # /app/foo.html, /app/qwe.jsp, etc) the object name # "server.example.com" NameTrans fn="assign-name" from="/app(|/*)" name="server.example.com" ... </Object> # Execute these instructions for any resource with the assigned name # "server.example.com" <Object name="server.example.com"> # Proxy the requested resource to the URL # "http://server.example.com:8080" Service fn="service-passthrough" servers="http://server.example.com:8080" user="blues" password="j4ke&elwOOd" </Object> |
The following obj.conf snippet demonstrates the use of auth-passthrough (note that these lines are not indented in a real obj.conf):
| <Object name="default"> AuthTrans fn="auth-passthrough" ... </Object> |
check-passthrough:
The check-passthrough ObjectType SAF checks to see if the requested resource (for example, the HTML document or GIF image) is available on the local server. If the requested resource does not exist locally, check-passthrough sets the type to indicate that the request should be passed to another server for processing by service-passthrough.
The check-passthrough SAF accepts the following parameters:
• type — (Optional) The type to use for files that do not exist locally. If not specified, type defaults to magnusinternal/passthrough.
service-passthrough
The service-passthrough Service SAF forwards a request to another server for processing.
The service-passthrough SAF accepts the following parameters:
• servers — A quoted, space-delimited list of servers that receive the forwarded requests. Individual server names may optionally be prefixed with http:// or https:// to indicate the protocol, or suffixed with a colon and integer to indicate the port.
• sticky-cookie — (Optional) The name of a cookie that causes requests from a given client to “stick” to a particular server. Once a request containing a cookie with this name is forwarded to a given server, service-passthrough attempts to forward subsequent requests from that client to the same server by sending a JROUTE header back to the client. If not specified, sticky-cookie defaults to JSESSIONID.
• user — (Optional) The username that service-passthrough uses to authenticate to the remote server via Basic-Auth. Note that ‘user’ requires that ‘password’ also be specified. Sun Microsystems, 6 Sun Java System Web Server Reverse Proxy Plug-in , Inc.
• password — (Optional) The password that service-passthrough uses to authenticate to the remote server via Basic-Auth. Note that ‘password’ requires that ‘user’ also be specified.
• client-cert-nickname — (Optional) Nickname of the client certificate that service-passthrough uses to authenticate to the remote server.
• validate-server-cert — (Optional) Boolean that indicates whether service-passthrough should validate the certificate presented by the remote server. If not specified, validate-server-cert defaults to false.
• rewrite-host — (Optional) Boolean that indicates whether service-passthrough should rewrite the Host header sent to remote servers, replacing the local server’s hostname with the remote server’s hostname. If not specified, rewrite-host defaults to false.
• rewrite-location — (Optional) Boolean that indicates whether service-passthrough should rewrite the Location headers returned by a remote server, replacing the remote server’s scheme and hostname with the local server’s scheme and hostname. If not specified, rewrite-location defaults to true.
• ip-header — (Optional) Name of the header that contains the client’s IP address, or "" if the IP address should not be forwarded. If not specified, ip-header defaults to Proxy-ip.
• cipher-header — (Optional) Name of the header that contains the symmetric cipher used to communicate with the client (when SSL/TLS is used), or "" if the symmetric cipher name should not be forwarded. If not specified, cipher-header defaults to Proxy-cipher.
• keysize-header — (Optional) Name of the header that contains the symmetric key size used to communicate with the client (when SSL/TLS is used), or "" if the symmetric key size name should not be forwarded. If not specified, keysizeheader defaults to Proxy-keysize.
• secret-keysize-header — (Optional) Name of the header that contains the effective symmetric key size used to communicate with the client (when SSL/TLS is used), or "" if the effective symmetric key size name should not be forwarded. If not specified, secret-keysize-header defaults to Proxy-secret-keysize.
• ssl-id-header — (Optional) Name of the header that contains the client’s SSL/TLS session ID (when SSL/TLS is used), or "" if the SSL/TLS session ID should not be forwarded. If not specified, ssl-id-header defaults to Proxy-ssl-id.
• issuer-dn-header — (Optional) Name of the header that contains the client certificate issuer DN (when SSL/TLS is used), or "" if the client certificate issuer DN should not be forwarded. If not specified, issuer-dn-header defaults to Proxy-issuer-dn.
• user-dn-header — (Optional) Name of the header that contains the client certificate user DN (when SSL/TLS is used), or "" if the client certificate user DN should not be forwarded. If not specified, user-dn-header defaults to Proxy-user-dn.
• auth-cert-header — (Optional) Name of the header that contains the DER-encoded client certificate in Base64 encoding (when SSL/TLS is used), or "" if the client certificate should not be forwarded. If not specified, auth-cert-header defaults to Proxy-auth-cert.
When multiple remote servers are configured, service-passthrough chooses a single remote server from the list on a request-by-request basis. If a remote server cannot be contacted or returns an invalid response, service-passthrough sets the status code to 502 Bad Gateway and returns REQ_ABORTED. This returns an error to the browser. This error can be customized in the Web Server by configuring a customized response for the 502 error code. When user and password are specified, service-passthrough uses these credentials to authenticate to the remote server using HTTP basic authentication. When one or more of the servers in the servers parameter are configured with a https:// prefix, client-cert-nickname specifies the nickname of the client certificate service-passthrough uses to authenticate to the remote server. Sun Microsystems, 7 Sun Java System Web Server Reverse Proxy Plug-in , Inc. Note that service-passthrough generally uses HTTP/1.1 and persistent connections for outbound requests, with the following exceptions:
• When forwarding a request with a Range header that arrived via HTTP/1.0, service-passthrough issues an HTTP/1.0 request. This is done because the experimental Range semantics expected by Netscape HTTP/1.0 clients differ from the Range semantics defined by the HTTP/1.1 specification.
• When forwarding a request with a request body (e.g. a POST request), service-passthrough does not reuse an existing persistent connection. This is done because the remote server is free to close a persistent connection at any time, and service-passthrough does not retry requests with a request body.
In addition, service-passthrough encodes information about the originating client in the headers named by the ip-header, cipher-header, keysize-header, secret-keysize-header, ssl-id-header, issuer-dn-header, user-dn-header, and auth-cert-header parameters (removing any client-supplied headers with the same name) before forwarding the request. Applications running on the remote server may examine these headers to extract information about the originating client.
Additional Resources
Sun Java System Web Server: www.sun.com/webserver
• Downloads: Web Server and Reverse Proxy Plug-in: http://www.sun.com/download/
• Security and reverse proxy information: http://wwws.sun.com/software/products/web_srvr/security.html
• Performance benchmarks: http://wwws.sun.com/software/products/web_srvr/benchmarks.html
No comments:
Post a Comment