Configuring HTTP and HTTPS Failover

The load balancer plug-in fails over HTTP/HTTPS sessions to another
application server instance if the original application server instance to
which the session was connected becomes unavailable. This section describes
how to configure the load balancer plug-in to enable HTTP/HTTPS routing and
session failover.

HTTPS Routing

The load balancer plug-in routes all incoming HTTP or HTTPS requests
to application server instances. However, if HTTPS routing is enabled, an
HTTPS request will be forwarded by the load balancer plug-in to an application
server using an HTTPS port only. HTTPS routing is performed on both new and
sticky requests.

If an HTTPS request is received and no session is in progress, then
the load balancer plug-in selects an available application server instance
with a configured HTTPS port, and forwards the request to that instance.

In an ongoing HTTP session, if a new HTTPS request for the same session
is received, then the session and sticky information saved during the HTTP
session is used to route the HTTPS request. The new HTTPS request is routed
to the same server where the last HTTP request was served, but on the HTTPS
port.

Configuring HTTPS Routing

The httpsrouting option of the create-http-lb-config command controls whether HTTPS routing is turned on or off for
all the application servers that are participating in load balancing. If this
option is set to false, all HTTP and HTTPS requests are forwarded as HTTP.
If set to true, HTTPS are forwarded as HTTPS requests. Set HTTPS routing when
creating a new load balancer configuration, or change it later using the asadmin set command.

Note –

For HTTPS routing to work, one or more HTTPS listeners must
be configured.

If https-routing is set to true,
and a new or a sticky request comes in where there are no healthy HTTPS listeners
in the cluster, then that request generates an error.

Known Issues

The Load Balancer has the following limitations with HTTP/HTTPS request
processing.

If a session uses a combination of HTTP and HTTPS requests,
then the first request must be an HTTP Request. If the first request is an
HTTPS request, it cannot be followed by an HTTP request. This is because the
cookie associated with the HTTPS session is not returned by the browser. The
browser interprets the two different protocols as two different servers, and
initiates a new session. This limitation is valid only if httpsrouting is
set to true.

If a session has a combination of HTTP and HTTPS requests,
then the application server instance must be configured with both HTTP and
HTTPS listeners. This limitation is valid only if httpsrouting is
set to true.

If a session has a combination of HTTP and HTTPS requests,
then the application server instance must be configured with HTTP and HTTPS
listeners that use standard port numbers, that is, 80 for HTTP, and 443 for
HTTPS. This limitation applies regardless of the value set for httpsrouting.