Proxy server and load balancer settings

The mid tier implementation is in a servlet filter, which overrides the HttpServletResponse.sendRedirect(String Url) method so that all redirects that the mid tier sends are relative. (The standard mid tier sends are relative. (The standard HttpServletResponse.sendRedirect(String Url) method makes the URLs absolute.)

To enable the filter, edit the web.xml file or use the servlet container's administration console to add the filter. See Enabling filter parameters.

Behavior when the servlet filter is inactive

If the filter is inactive, redirect URLs in the Location HTTP header of the response sent from the mid tier by using the following format:

"http[s]://<localWebServerName>.<domainName>.com/arsys/path/to/resource"

In this example, <localWebServerName>.<domainName>.com is the host name or domain name where the servlet engine is running. That host name or domain name is incorrect in reverse proxy and load balanced environments.

Some proxy servers cannot overwrite <hostName>.<domain> in the Location HTTP header of the redirect response. Those proxy servers cannot connect the URL back to the proxy server's <hostName>.<domain>. The URL sent to the browser in these cases is not connected back through the proxy server, but includes a host name that is not resolvable or routable from the external network.

When the host name changes from the original URL that is used to initially connect through the proxy, the browser does not send the proper cookies that the servlet engine and mid tier set for session tracking and other functions. The URL in the Location HTTP header of redirect responses is sometimes wrong in load-balanced environments, because the local host name of one of the web servers in the server farm does not match the virtual host name of the load balancer.

If the filter is not active, the URL in the redirect response is:

"http[s]://<internalServerSomewhereOnAnother>.<internalDomain>.com/arsys/shared/login.jsp"

This URL cannot make it back through the proxy server.

Similar problems occur with cookies that the servlet engine and mid tier return. Some proxy servers cannot change the Set-Cookie HTTP header to reset the path on cookies to the proxy server's alias for web applications behind the proxy. In these cases, the proxy has an alias that directs requests to different internal web servers (for example, http[s]://external.hostname.somewhere.com/helpdesk directs HTTP requests to a mid tier application, and http[s]://external.hostname.somewhere.com/marketing directs HTTP requests to a different internal web server). The path for cookies that the servlet API returns is incorrect, and the following actions must occur:

• The proxy server must adjust the path. By default, the servlet API sets the cookie path to the name of the application context path. For the mid tier, the path usually is /arsys.
• The filter parameters must be enabled as described in Enabling filter parameters. You can reset the path for cookies to /helpdesk or simply to the root path (/).

Behavior when the servlet filter is active

If the filter is active, redirect URLs in the Location HTTP header of the response sent from the mid tier using the following format:

"../../../../path/to/resource"

The browser receives this relative URL and calculates the full URL to access the resource. For example, when the filter is active, the redirect to the login.jsp response from the URL:

http[s]://<correctProxyServerName>.  <correctDomain>.com/arsys/forms/arserver1/sampleForm/sampleView

to login.jsp is similar to:

"../../../../shared/login/jsp"

Enabling filter parameters

1. Open the mid tier application's web.xml file.
2. Locate the <listener> tag.

3. Add the following code just before the <listener> tag:

   <filter>
   <filter-name>ProxyFilter</filter-name>
   <filter-class>com.remedy.arsys.stubs.ProxyFilter </filter-class>
   </filter>
   <!--Optional init parameter for setting the cookie path - uncomment to enable and set accordingly
   <init-param>
   <param-name>cookie-path</param-name>
   <param-value>/</param-value>
   </init-param>
   -->
   <filter-mapping>
   <filter-name>ProxyFilter</filter-name>
   <url-pattern>/*</url-pattern>
   </filter-mapping>

Following is a sample of the web.xml file after the filter is enabled:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN' 'http://java.sun.com/dtd/web-app_2_3.dtd'>
<!--
Copyright (c) 2004 BMC Software, Inc.
All rights reserved.
This software is the confidential and proprietary information of
BMC Software, Inc ("Confidential Information"). You shall not
disclose such Confidential Information and shall use it only in
accordance with the terms of the license agreement between
you and BMC Software, Inc.
-->
<!--
The web-app element is the root of the deployment descriptor for a web application
<!ELEMENT web-app (icon?, display-name?, description?, distributable?, context-param*, servlet*, servlet-mapping*, session-config?, mime-mapping*, welcome-file-list?, error-page*, taglib*, resource-ref*, security-constraint*, login-config?, security-role*, env-entry*, ejb-ref*)>
-->
<web-app>
<display-name>Remedy AR System</display-name>
<filter>
<filter-name>ProxyFilter</filter-name>
<filter-class>com.remedy.arsys.stubs.ProxyFilter </filter-class>
</filter>
<!--Optional init parameter for setting the cookie path - uncomment to enable and set accordingly
<init-param>
<param-name>cookie-path</param-name>
<param-value>/</param-value>
</init-param>
-->
<filter-mapping>
<filter-name>ProxyFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<listener>
<listener-class>
			com.remedy.arsys.stubs.SessionData$ReleaseSessionData
			</listener-class>
</listener>
<servlet>
<servlet-name>SetupServlet</servlet-name>
<servlet-class>com.remedy.arsys.stubs.SetupServlet
			</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<!-- Session related servlets -->
(... Rest of web.xml file ...) 

Proxy servers

A proxy server services its clients' requests by forwarding requests to other servers. A client connects to the proxy server to request a service (such as a file, connection, web page, or other resource) that is available from a different server. The proxy server connects to the specified server and requests the service on behalf of the client. Optionally, a proxy server can alter the client's request or the server's response. It can also serve the request without contacting the specified server.

The mid tier does not provide out-of-the-box proxy services, but it can use third-party proxy servers.