Please note that this BLOG is now outdated. In SCN, you will now find the most up to date version of all WebDispatcher information here: https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=414089394
I will soon remove this BLOG, so please update your bookmarks!
General
Where do I find the Online Documentation?
Online documentation for Web Dispatcher is found on help.sap.com.
- The current path to the documentation (version 7.4x): help.sap.com => SAP NetWeaver => SAP NetWeaver 7.4 => Application Help => Function-Oriented View <Langauge> => Application Server => Application Server Infrastructure => Components of SAP NetWeaver Application Server ABAP => SAP Web Dispatcher.
- Documentation for version 7.2x: help.sap.com => SAP NetWeaver => SAP NetWeaver 7.3 => Application Help => SAP Library => Administration Information => Technical Operations for SAP Netweaver => Administration of Standalone Engines => Technical Operations of SAP Web Dispatcher.
How do I configure Web Dispatcher to redirect URL ‘/’ to a custom start URL?
You can use the Web Dispatcher modification handler for this purpose. For a full documentation of the modification handler refer to the Netweaver 7.3 online documentation of the modification handler
If you simply want to redirect URL ‘/’ to a defined start URL you can follow the instructions below.
In the example the file is called rules.txt and located in the Web Dispatcher instance directory. To use a different name or location adopt the profile parameter accordingly.
The file has the following content: RegRedirectUrl ^/$ /index.html
Then you need to add a profile parameter to the Web Dispatcher profile: icm/HTTP/mod_0 = PREFIX=/,FILE=$(DIR_INSTANCE)/rules.txt
Then you need to restart Web Dispatcher.
Now requests for URL ‘/’ (or requests with an empty URL path in the browser) are redirected to /index.html
As an alternative to configuring this redirect in Web Dispatcher it is possible to configure it in ICF.
Can Web Dispatcher forward requests across an HTTP proxy?
Yes. Web Dispatcher can forward requests to arbitrary systems even across proxy servers using the EXTSERV and PROXY directives to the wdisp/system parameter . See note 1971571 – Web Dispatcher new features: Proxy connect and cookie filter for details. Beware of the security risks explained in the attachment of that note!
Web Dispatcher does not change the Host header. Is this configurable?
No. SAP systems support name-based virtual hosting. For this to work, the Host header must mot be changed by the intermediary. As a matter of fact, if you use Apache as an intermediary in front of an SAP Application Server, you must configure “ProxyPreserveHost On” to prevent Host header modification.
If you really must modify the Host header, for example, to satisfy an EXTSERV external system, you can use the Web Dispatcher’s rewrite handler to manipulate header fields.
Is SAP Web Dispatcher a reverse proxy?
There is no single definition of “reverse proxy” and it seems that everybody has a slightly different opinion on the exact meaning of the term. The HTTP protocol definition RFC 2616 does not mention the term “reverse proxy” at all. In the terminology of RFC 2616 the SAP Web Dispatcher is a gateway:
“Gateway: A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway.
The term “reverse proxy” is just a common synonym for such a “gateway”, and since it’s more common, let’s stick with it. In addition to the RFC 2616 definition, reverse proxies can have many features. Most common are the following:
- SSL termination and off-loading
- Load balancing
- Caching
- Compression
- Decoupling of servers from slow front-end networks
- Virtual hosting of multiple backend systems behind a single IP address
- Request filtering based on simple rules, like URL paths
- Sophisticated application firewall features against web-based attacks
- Authentication and single-sign-on (SSO)
- Authorization of resource access per user
SAP Web Dispatcher provides all of these features except the last three.
So the answer is: SAP Web Dispatcher is a reverse proxy. However, there are other reverse proxies that offer features that SAP Web Dispatcher does not have.
Can I run Web Dispatcher on the same host as an ABAP / JEE / HANA system?
Yes. Web Dispatcher does not usually consume a lot of resources, usually about 2 GB memory and little CPU. For more info see note 2007212 – Tuning SAP Web Dispatcher and ICM for high load.
How can I tune Web Dispatcher for high load?
See note 2007212 – Tuning SAP Web Dispatcher and ICM for high load. It applies to 7.40 and following versions.If you need to continue using 7.20, the parameter recommendations are similar, but:
- In 7.20 it is not possible to enter formulas as profile parameter values, therefore you have to calculate the results of the formulas yourself and anter them as numbers into the profile (e.g. assuming icm/max_conn is 16000, then set wdisp/HTTP/max_pooled_conn=16000).
- The maximum of icm/max_conn is 16000, even for Windows, Linux, AS/400, AIX.
What is the difference between Internet Communication Manager (ICM) and Web Dispatcher?
ICM is the Web server used by the ABAP and J2EE application servers. They are part of a single instance of the application server and forward requests only to the work processes of that instance. ICM cannot route requests another system.
Web Dispatcher is a load balancer and reverse proxy. It sits typically in front of multiple instances of one system and possibly in front of multiple systems. It can perform request routing based on rules.
What are the Virtual Hosting options?
Virtual hosting is the ability to host separate different entities in a single physical web server. These could be different backend systems or different clients within a single system or other origin web servers that serve as backend servers. Web Dispatcher supports different models of virtual hosting:
- Name-based virtual hosting is configured with the sub-parameter SRCVHOST of the wdisp/system configuration parameter.
- IP-based and port-based virtual hosting is configured with the SRCSRV sub-parameter.
Configuration of the SAP Web Dispatcher for Back-End Systems describes the usage of the wdisp/system parameter in detail.
We recommend using virtual hosting based on the SRCVHOST parameter if access two all systems behind the SAP Web Dispatcher is allowed for all clients. On the other hand, if access to some systems needs to be restricted by means of physical network isolation, then physical request criteria like IP address or port have to be used.
Note that SAP Web Dispatcher currently (as of release 7.42) does not support Server Name Indication. That means each server port can only serve a single SSL certificate. If you want to serve multiple names on a single port, you need to use a wildcard certificate.
How many SAP Web Dispatchers do I need
SAP Web Dispatcher supports multiple systems to be served by a single SAP Web Dispatcher executable. See “Virtual Hosting Options” above for a description of how to configure such a setup. Reasons for using separate SAP Web Dispatcher installations could be:
- Load – SAP Web Dispatcher scales well on hardware with multiple cores. Using parallel SAP WebDispatcher installations on parallel hosts is necessary only in scenarios with very high load (above 10.000 request per second).
- Administration and lifecycle management – It makes sense to use separate SAP Web Dispatchers for dev, test and prod landscapes to keep the latter as stable as possible while the former can be changed to support different scenarios or updated to newer versions more frequently. Mostly two installations are sufficient, one for prod and one for the rest. SAP Web Dispatcher is downward compatible and therefore changes usually don’t affect other systems very strongly.
- Security – If one landscape or system needs to be as operated in strong isolation from other systems, it makes sense to use a separate SAP Web Dispatcher for that system or landscape.
Can I use a different load balancer instead of SAP Web Dispatcher
Positioning
Web Dispatcher provides an easily consumable Web infrastructure solution for most SAP products based on Web AS ABAP, Web AS Java or HANA XS. It is free of charge, low in TCO yet high in performance and perfectly supports SAP systems and their load balancing and request routing features out of the box.
However, SAP Web Dispatcher is not a mandatory component of SAP systems or solutions – since HTTP is a standardized protocol, other Web infrastructure products can be used as well. Customers are free to use a load balancer or reverse proxy of their choice.
Possible reasons for using a third party load balancer
We cannot speak for individual products here, but rather generally of benefits that some third party components may offer over SAP Web Dispatcher. Specific features have to be clarified for the individual product and concrete usage scenario.
- Investments or strategic decisions in a third party infrastructure have already been made.
- Functionality that SAP Web Dispatcher does not have, for example Web Application Firewall (WAF) or access control.
- Very high scalability or strict availability requirements.
A single SAP Web Dispatcher can handle roughly 10,000 concurrent users, which varies depending on usage characteristics and host operating system. Higher load requires a third party load balancer. It is possible to operate multiple SAP Web Dispatchers behind a (simple) third party load balancer to enhance scalability and availability and still benefit from the special integration features of SAP Web Dispatcher with SAP backend systems. For high availability, SAP Web Dispatcher can also be operated in a failover cluster.
Possible issues when using third party load balancers
HTTP is a standardized protocol, but the interpretation of the standard is subject to many ambiguous decisions. Different design decisions in the applications require appropriate handling of HTTP requests by the load balancer/reverse proxy.
SAP Web Dispatcher supports the idiosyncrasies of SAP servers and applications out of the box. For example, SAP servers require that the Host header remains unchanged, while other servers require it to be changed to the server’s host name. Third party infrastructures may require explicit configuration to ensure that SAP applications run smoothly.
Unique features – Apart from the hard requirements, SAP Web Dispatcher is integrated with SAP backend systems. It offers for example
- Fine-grained control of stickiness in cooperation with applications to distinguish stateful from stateless requests and detect user log-off.
- Availability checks of the application servers.
- Logon groups for application-specific load distribution.
- Certificate forwarding for X.509 certificate-based authentication.
- Automatic configuration retrieval from backend systems (running servers and their capacity, logon groups, configured applications).
None of these are mandatory, therefore customers can chose to build a solutions without them or implement them with third party load balancers themselves.
Some SAP solutions require setups where multiple systems are integrated into a single logical system, like in landscapes with SAP Enterprise Portal and Fiori. SAP usually tests and documents the configuration of such landscapes only with SAP Web Dispatcher.
Customers are responsible for the correct setup of SAP scenarios using third party load balancers, including:
- Translate the configuration descriptions of SAP Web Dispatcher into configuration for the used load balancer.
- Implement required features, like stickiness as needed.
- Implement additional features, like availability checks or certificate forwarding.
SAP cannot provide descriptions for such configurations due to the multitude of available products. The customer has the sole responsibility for the setup. In case of issues, troubleshooting may be more difficult if a third party load balancer is used due to lack of specific knowledge by SAP support staff.
Project complexity is another aspect worth considering. SAP Web Dispatcher is usually administered by SAP Basis administration, while hardware load balancers usually belong to the network department. This requires a project to span organizational boundaries to allow agile configuration changes and efficient operation.
Security
Is Web Dispatcher vulnerable to Shellshock attacks?
Web Dispatcher or Internet Communication Manager (ICM) do not contain a CGI interface or start any executables with environment variables that depend on request input. Therefore, they are not vulnerable to the Shellshock class of attacks.
How do I configure Web Dispatcher as a URL filter?
You can use the Web Dispatcher modification handler for this purpose. For a full documentation of the modification handler refer to the Netweaver 7.3 online documentation of the modification handler
In the example all requests for URLs which do not start with ‘/sap/’ are forbidden. The rule file is called rules.txt and located in the Web Dispatcher instance directory. To use a different name or location adopt the profile parameter accordingly.
The file has the following content:
RegIForbiddenUrl !^/sap/(.*) –
Then you need to add a profile parameter to the Web Dispatcher profile:
icm/HTTP/mod_0 = PREFIX=/,FILE=$(DIR_INSTANCE)/rules.txt
Then you need to restart Web Dispatcher.
Now requests for URLs which do not start with ‘/sap/’ receive an HTTP 400 Forbidden response.
Default request filters of ICM and Web Dispatcher
ICM and Web Dispatcher use the so-called CSA library for scanning requests. It is configured with the parameter csi/enable which is by default = 1. The content scan rules are described here:
1) The URL is scanned for compliance with the URI standard defined in http://tools.ietf.org/html/rfc2396#appendix-A.Non-compliant URLs are rejected with an HTTP status code 400 “Bad Request”.
2) Request bodies <64 kB with content type application/x-www-form-urlencoded are scanned for occurrence of disallowed strings with the following regular expression patterns:
<\s*(script|object|iframe|embed|img)[^>]*>(.*)<\s*/(script|object|iframe|embed|img)\s*>
[a-z]{0,5}script\:
<\s*/script\s*>(.*)//
If a request contains any of these, it is rejected with HTTP code 403 “Access Denied”. If request bodies are bigger than 64 kB or have other content types, like multipart/form-data, they are not scanned.For more info, see
http://help.sap.com/saphelp_nw74/helpdata/en/4e/2606b7c61920cee10000000a42189c/content.htm
http://help.sap.com/saphelp_nw74/helpdata/en/4e/2606c0c61920cee10000000a42189c/content.htm
Thanks for compiling the FAQ for WebDispatcher. I will include this link in the collection of SAP Fiori – Installation.
Much needed info.
Do you know if we can add “secure” attribute to cookies? Is it via rewrite file at the SAP web dispatcher?
Background is below,
NEW PCI FAIL – QID 150122 Cookie Does Not Contain The “secure” Attribute
Br,
Shruthi