Configuring the Apache HTTP Server

Configuring the Apache HTTP Server

This section elaborates on the ICEsoft recommended configurations for running ICEfaces applications on application servers with an Apache HTTP Server as the front-end. ICEfaces EE supplies the Asynchronous HTTP Server which is spawned inside the application server of choice. The Apache HTTP Server is therefore responsible for filtering the incoming HTTP requests and forwarding the blocking requests to the Asynchronous HTTP Server and all other requests to the application server. A configuration such as this is mandatory to have full support for all mainstream Internet browsers. Refer to Figure 2 .

Note: Throughout this section, we use boldface text for variables used in the code examples that should be replaced as required.

Routing Requests

To route all blocking requests to the Asynchronous HTTP Server and all other requests to the application server, add the following code to the end of the Apache configuration file:
<IfModule mod_proxy.c>
 
    ProxyRequests Off
 

 
    <Proxy *>
 
        Order deny,allow
 
        Allow from all
 
    </Proxy>
 

 
    # The following two directives will route all blocking requests to the
 
    # Asynchronous HTTP Server (identified by host:port)
 
    ProxyPass        /application-name/block/receive-updates
 
                     http://host:port/application-name/block/receive-updates
 
    ProxyPassReverse /application-name/block/receive-updates
 
                     http://host:port/application-name/block/receive-updates
 

 
    # The following two directives will route all other requests to the
 
    # application server (identified by host:port)
 
    ProxyPass        /application-name
 
                     http://host:port/application-name
 
    ProxyPassReverse /application-name
 
                     http://host:port/application-name
 
</IfModule>
 

 
If multiple ICEfaces applications are deployed behind the Asynchronous HTTP Server, multiple ProxyPass and ProxyPassReverse directives should be included, two sets for each application. If an Apache HTTP Server plugin is used, which is discussed in Apache HTTP Server Plugins on page 14, the last ProxyPass and ProxyPassReverse set can be omitted.

Note: It is critical that the port number, mentioned in the first ProxyPass and ProxyPassReverse set, matches the port number in the Asynchronous HTTP Server's configuration file, which is discussed in Configuring the Asynchronous HTTP Server on page 10 . Evidently the port number, mentioned in the second ProxyPass and ProxyPassReverse set, should match the port number of the application server.

In order to have proxy support in the Apache HTTP Server the mod_proxy and mod_proxy_http modules are required. In the Apache configuration file where all modules are being loaded, add the following if not already added:
LoadModule proxy_module modules/mod_proxy.so
 
LoadModule proxy_http_module modules/mod_proxy_http.so
 
For more information on how to load modules into Apache HTTP Server, refer to Apache Module mod_so which can be found at:

http://httpd.apache.org/docs/2.2/mod/mod_so.html

Security Considerations

Authentication

To enforce authentication of the user when accessing an ICEfaces application, add the following code to the Apache configuration file:
<LocationMatch ^/application-name>
 
    AuthName "ICEfaces Member-Only Access"
 
    AuthType Basic
 
    AuthUserFile /var/www/secrets/.members
 
    require valid-user
 
</LocationMatch>
 
The <LocationMatch regex> container determines that every location (Request-URI), which begins with (^) the literal string "/application-name" where the application-name is the name of the ICEfaces application, is part of the ICEfaces Member-Only Access realm and, therefore, requires basic authentication for every user.

Secure Sockets Layer (SSL)

1. To enforce the usage of SSL when accessing an ICEfaces application, add the following code to the Apache configuration file:
RewriteEngine On
 
RewriteCond %{SERVER_PORT} ^80$
 
RewriteCond %{REQUEST_URI} ^/application-name
 
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [R=301,L]
 
The RewriteCond directives define the following conditions:

if the port address of the server (%{SERVER_PORT}) begins with (^) and ends with ($), thus exactly matches the literal string "80"; and
if the Request-URI (%{REQUEST_URI}) begins with (^) the literal string "/application-name", where the application-name is the name of the ICEfaces application.

If both of the previous conditions are met, the RewriteRule directive defines how the Request-URI is rewritten to use HTTPS as follows:

$1 corresponds to the string found in the set of parentheses (that is, everything after the root (/)); and
rewrite the Request-URI to https://%{HTTP_HOST}/$1, where %{HTTP_HOST} is the server's host name.

2. After rewriting the Request-URI, force an external redirect (301 Moved Permanently) to the client (R=301).

3. Finally, tell the rewrite engine to end rule processing immediately (L), so that no other rules are applied to the last substituted Request-URI.

Apache HTTP Server Plugins

Plugins are modules that can be added to the Apache HTTP Server installation and can be configured to enable interaction between the server and the application server of choice. Typically, plugins can be used as a load balancer for the server by proxying the requests to the back-end application servers, or can be used to proxy requests for dynamic content to the back-end application server(s).

JBoss 4.0

JBoss uses the Apache Tomcat Servlet container, which is configured with the Apache HTTP server via the Tomcat plugin known as mod_jk.

1. First copy the mod_jk.so module supplied by the Apache Software Foundation into the Apache HTTP Server's /module directory. You can obtain this module from the following web site link:
http://tomcat.apache.org/connectors-doc/install/apache2.html

2. Create a new file called mod_jk.conf in the Apache HTTP Server's /conf directory and add the following to it:
LoadModule jk_module modules/mod_jk.so
 

 
JkWorkersFile conf/workers.properties
 
JkLogFile /var/log/httpd/mod_jk.log
 
JkLogLevel info
 
JkMount /* myworker1
 
3. Create a new file called workers.properties in the same directory and add the following to it:
worker.list = myworker1
 

 
worker.myworker1.port = 8009
 
worker.myworker1.host = localhost
 
worker.myworker1.type = ajp13
 
worker.myworker1.lbfactor = 1
 
The ajp13 refers to a worker inside JBoss that listens to port 8009. This example shows both the Apache HTTP Server and JBoss running on the same machine (hence, the localhost has the hostname of myworker1), but it is recommenced to run the Apache HTTP Server and JBoss instances on separate machines.

4. Finally, the mod_jk.conf needs to be loaded. To achieve this, add the following to Apache HTTP Server's configuration file right after the LoadModule directives:
Include conf/mod_jk.conf
 
For more information on how to install and configure Apache Tomcat's plugin, refer to the Server Configuration Reference for Apache Tomcat 5.0.x and Apache Tomcat Configuration Reference for Apache Tomcat 5.5.x which can be found at:

http://tomcat.apache.org/tomcat-5.0-doc/config/ajp.html

WebLogic Server 8.1 Service Pack 4

The following is a simple solution for installing and configuring WebLogic's plug-in for the Apache HTTP Server.

1. First, copy the mod_wl_20.so module supplied by WebLogic into the Apache HTTP Server's /module directory.

2. Add the following code to the Apache configuration file:
LoadModule weblogic_module modules/mod_wl_20.so
 
...
 
<IfModule mod_weblogic.c>
 
    WebLogicHost host
 
    WebLogicPort port
 
</IfModule>
 
For more information on how to install and configure WebLogic's plug-ins, refer to BEA WebLogic Server - Using Web Server Plug-Ins with WebLogic Server, which can be found at:

http://e-docs.bea.com/wls/docs81/pdf/plugins.pdf

Routing Requests

In order for the plug-in to handle all the requests to the ICEfaces application with the exception of the asynchronous requests, add the following code to the Apache configuration file:
<LocationMatch ^/application-name(?!/block/receive-updates)>
 
    SetHandler weblogic-handler
 
</LocationMatch>
 
To explain the regular expression used in the <LocationMatch regex> container, the following is a breakdown:

^/application-name if the location begins with (^) the literal string "/application-name" where application-name is the name of the ICEfaces application.

and

(?!/block/receive-updates) is not followed by (?!) the literal string "/block/receive-updates".

This regular expression ensures that the following possible locations get handled by the plug-in:

/application-name (initial request)
/application-name/ (initial request)
/application-name/xmlhttp/icefaces-d2d.js (part of initial request)
/application-name/block/receive-send-updates?query (synchronous request)
/application-name/block/send-updates?query (UI request)

But it prevents that the following possible location gets handled by the plug-in:

/application-name/block/receive-updates?query (asynchronous request)