End-to-End SSL 
Functions
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.
For more information, see SAP Web Dispatcher and SSL
Configuration
It is very easy to configure end-to-end-SSL. For parameter icm/server_port_<xx> you set the protocol to the value ROUTER.
Restrictions
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
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.
Configuration
You can use profile parameter wdisp/HTTPS/sticky_mask to group several client IP addresses into a logical address. The exact function of the parameter is described in SSL Parameters.
Default is: A bitwise AND operation on mask 255.255.240.0 and the real IP address is executed; this hides the lowest 12 bits, that is, 124.94.55.1 and 124.94.55.99 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 also depends 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. The exact function of the parameter is described in SSL Parameters.
Be aware that 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 parameter wdisp/HTTPS/dest_logon_group (see SSL Parameters) you define a logon group with HTTPS-enabled application servers, to which all HTTPS request are then sent.
ABAP or J2EE Server
Since the SAP Web Dispatcher cannot decide whether a request should be processed by an ABAP or a Java 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
More Information
Parameterization of the SAP Web Dispatcher