Often, if a short form of an URL is used in the browser to address a specific host, for example http:// myHost/URL or an IP adddress, for example http:// 12.34.56.78/URL, this results in a short dump requesting that a Fully Qualified Domain Name (FQDN) be used. Here are described background information, problems and how to indentify these.
URL does not specify a complete domain (sapdev instead of sapdev.<domain>.<ext>)
Problem Description
If the host name only specifies the host and port but not the domain (including the extension), the shortened URL of a BSP application appears as follows:
Abstract Form: <protocol>://<hostname>:<port>/sap/... Example: http://pwdf0487:1080/sap/bc/bsp/sap/it00/default.htm
However, the BSP runtime does NOT accept URLs in this form, and insists and enforce the use of a fully qualified domain name (FQDN). The URL must be have the follows format:
Abstract Form: <protocol>://<host name>.<domain>.<ext>:<port>/sap/... Example: http://pwdf0487.wdf.sap.corp:1080/sap/bc/bsp/sap/it00/default.htm
The main reasons for this, is:
- Requiring a domain with which to set domain wide cookies, for example SSO2 cookies.
- Domain relaxation coding required for cross frame JavaScript code. This is especially important for portal integration.
- HTTPS: For certificates and SSL protocol it is required to have matching names from what the client and server thinks.
Important is that the domain in which the WebAS is running, might not be (and does not have to be) the FQDN from which the browser is accessing the WebAS. A typical example is a WebAS running in both Intranet and Internet. The FQDN is determined by the browser's position relative to WebAS, and can not be set or determined by the WebAS. Important is just that the browser actually does use a FQDN to access the WebAS.
IP Addresses
A variation of the same problem is where IP addresses are used instead of FQDN. This leads to diverse problems, for example SSO2 cookies are suddenly set on domains of the form *.34.56.78. This adds the rule that also the use of IP addresses are not supported in the URL, and FQDN is enforced. Specifically reference SAP Note 620SP31+: Fully Qualified Domain Names Check.
Solution Space
There is NO alternative solution supported. FQDN URLs must be used. Reference Naming Requirements for Hostnames and Domains for one idea as to temporarily workaround this problem. However, it does require a local configuration change on each and every client, and can only be a temporary solution. The alternative idea for testing only, is to manually correct the URL in the browser and to start the application new. One approach would be to inform the WebAS of the FQDN it should use for URL generation using the profile parameter icm/host_name_full parameter. For example, instead of myHost, use myHost.domain.ext. If several application servers are operated with one instance profile, you could consider the following approach: icm/host_name_full = $(SAPLOCALHOST).domain.ext.
References
- Naming Requirements for Hostnames and Domains
- BSP In-Depth: Fully Qualified Domain Names
- Configuration for fully qualified host names for BSP
- Domain restrictions in a portal environment
- URL requirements due to Internet standards
- 620SP31+: Fully Qualified Domain Names Check
- FQHN determination in ICM
- Configuration for FQDN
1 Comment
Mike Howles
There is the solution of applying an ABAP Enhancement to the CX_FQDN class in the CHECK method to check a ZTABLE for possible variants of the host name. I have done this at home with NW 7.01 ABAP trial without issue. This does not require a change to SAP's code if you do it as an ABAP Enhancement.