Show TOC

End-to-End SSLLocate this document in the navigation structure



Unlike HTTP, with end-to-end SSL the SAP Web dispatcher cannot read any request data and therefore cannot interpret any session cookies that may be available (with stateful applications). The necessary information for forwarding the request to the correct server is therefore missing. Neither does the SAP Web dispatcher know whether the request belongs to a stateless or a stateful application.

As a result, the SAP Web dispatcher forwards the encrypted data unchanged to the application server, where the data is finally decrypted.

The only distinguishing criterion available to the SAP Web dispatcher is the client IP address. As a result, the SAP Web dispatcher maintains a mapping table between the client IP address and the application server. If a request from a client IP address is sent to application server X, all subsequent requests from this client IP address must also be sent to this sever, since it could well be a stateful application. Load balancing therefore only takes place upon the very first client request.


We recommend that you configure the SSL termination. This is more work for the Web Dispatcher since it must decrypt SSL, but once it does all the information required for optimizing load balancing will be available.


It is very easy to configure end-to-end-SSL. For parameter icm/server_port_<xx> you set the protocol to the value ROUTER.


All configurations that depend on knowing what the HTTP contents are have no effect:

  • Configuration of HTTP redirects

  • Configuration of error pages in the Web Dispatcher

  • Configuration of file handlers

  • Configuration of an HTTP cache in the Web Dispatcher

  • Access to the Web administration interface of the Web Dispatcher using SSL

  • Configuration of an HTTP access protocol

  • Configuration of URLs to reject and permit

  • Configuration of System Selection with Multiple Systems

The problems described below also occur:

  • Use of proxies

  • Protocol switch for stateful requests

Using Proxies

All companies use proxies. This means that requests that are sent via a proxy are sent to one server. As a result, this cancels load balancing with the first request.

Large companies use several parallel proxies (which in turn also balance load) to access the Internet. This means that a request from the same client is sent via proxy A, and a later request from the same client, belonging to the same session, is sent via proxy B to the SAP Web dispatcher, and therefore has a different client IP address.


You can use profile parameter wdisp/HTTPS/sticky_mask to group several client IP addresses into a logical address.

The default is: A bitwise AND operation on mask and the real IP address is executed; this hides the lowest 12 bits, that is, and are then interpreted as the same.

Mapping Table

The mapping table, which is used by the SAP Web dispatcher to manage client IP addresses and the assigned application severs has the following properties.

  • The size of the mapping table depends also on the sticky mask. The more bits are hidden, the smaller is the mapping table. Profile parameter wdisp/HTTPS/max_client_ip_entries defines the maximum number of entries that this table can hold.


    Note the following: If the mapping table is full, that is, the value of wdisp/HTTPS/max_client_ip_entries has been reached, the SAP Web dispatcher no longer balances the load! The parameter should therefore always be set according to your needs and resources.

  • If a server is shut down, the context is deleted on this server. The system looks for a new server for this client IP address. With parameter wdisp/HTTPS/context_timeout, you can specify the timeout for entries in the client IP table (in seconds, default value 3600). An entry is deleted from the table, if no request has arrived from this client IP address within the time specified. The value must always be larger than the session timeout of the application server.

Protocol Switch for Stateful Applications

With stateful applications it is not possible to switch between HTTP and HTTPS.

This is because each protocol has different mechanisms to forward stateful requests to the application servers.

If the HTTP protocol is used, the status information is used in the HTTP data (cookie, URL or semicolon parameter). If the HTTPS router protocol is used, the client IP address is used to forward HTTPS requests from one client always to the same application server.

In addition to not being able to switch the protocol, you cannot guarantee that requests from one session are always forwarded to the same application server.

Selecting a Suitable Application Server

HTTPS-Enabled Application Server

With the parameter wdisp/HTTPS/dest_logon_group, you define a logon group with HTTPS-enabled application servers, to which all HTTPS request are then sent.

ABAP or Java Server

Since the SAP Web Dispatcher cannot decide whether a request should be processed by an ABAP or a Java appliation server, all servers in the logon group for HTTPS requests must provide the same services. Of course, all servers must be HTTPS-enabled, and one of the following points must apply:

  • All servers offer Java and ABAP

  • All servers offer ABAP only

  • All servers offer Java only