BSP In-Depth: Fully Qualified Domain Names

Every once in a while, this error message comes back to haunt us:

In synchronized translation: “BSP Exception: The URL does not contain a full domain specification (ls0028 instead of ls0028.wdf.sap-ag.de).”

Lovingly, this is referred to as the “Fully Qualified Domain Name” problem. FQDN requires that the hostname must be specified with a complete domain name when addressing the server.

For example:

Usually only the host name in the URL is required for the browser to determine the IP address to use. In the above example, ls0028 can easily be resolved to the correct IP address without the requirement of a domain name. See:

In the first instance, the hostname part of the URL is only for the browser to find a route to the Web server. Once on the Web server, the rest of the path starting at / is used to resolve the specific page to view.

So why would BSP require an FQDN and other services would not?

Motivation for FQDN

The first interesting aspect to understand is that the host name in the URL is effectively a routing string, which tells the browser how to reach the target. A typical situation is that a host might have an intranet name (example ls0028.wdf.sap-ag.de) that is totally different from the Internet name (example bsp.sap.corp – name changed to protect the innocent:). The name entered in the URL is important for the SAP Web AS, as this tells us the route that was followed to the server.

This host name is always placed into the HTTP header (header field “Host:”). The information is available on the server as to what the browser thinks the correct name is.

There are three big reasons why the browser must access the Web AS with FQDN.

• Use of HTTPS protocol. The SSL protocol requires that the server and browser names match the names in the certificates (if used).
• When setting cookies for a specific domain, it’s important to know the domain the browser requires for the cookie, so that the cookie will always be returned to the server. A typical example is the SSO2 cookie used for Single Sign-On over multiple servers.
• For Java Script calls to work over different frames (from different hosts in the same domain), each frame must relax its document domain. Typically the hostname is stripped, and the domain is set to the FQDN. For this to work, the browser must already know the FQDN for the document that it’s retrieving. This information cannot be set from the server and must be correct from the beginning of the request.

Especially for the domain relaxation aspect, the BSP runtime cannot know beforehand if this will be used for the application. If FQDN is not enforced, it just opens the potential for many other types of more difficult-to-diagnose problems.

ICM Configuration

Usually, FQDN and its use are a browser-related problem. The URL is entered at the browser and should be correct.

However, there are many cases where a URL is created at the server. One typical example is when a BSP application is tested in the SE80. A browser window is opened with the URL to test. In this case of course, the URL must also be a FQDN!

Usually the ICM picks up the correct domain for the server from a Domain Name Server (DNS). However, there are many cases where this does not work accurately. For them, ICM supports a profile parameter icm/host_name_full. We recommend you configure this parameter at all times. This is the hostname that will be used to build fully qualified URLs.

References

http://help.sap.com/saphelp_webas620sp19/helpdata/en/61/f5183a3bef2669e10000000a114084/content.htmICM Configuration. Specifically icm/host_name_full.

For domain settings see OSS/CSN Note http://service.sap.com/~form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=434918434918.

Final War Story

Yesterday, a colleague ran into the office. They had a demo in 30 minutes for customers, and nothing worked. It turns out they had configured their system to use IP addresses inside the URL, and unfortunately this was not detected by our naïve domain detection algorithm. Result: the SSO2 cookie was set for domain “*.21.80.168” and failed to work. We immediately reworked that FQDN check!