BSP In-Depth: URL Mangling

What is URL Mangling?

Usually when accessing a website, the URL of the page is shown exactly as entered.

However, for BSP applications, once a URL is entered, it has a nasty habit of changing itself quickly.

This process we call URL mangling and it’s interesting to look at this in more detail.

The first question is always “What is hidden inside the URL?” Usually, the client and language is written into the URL. However, there are a number of other additional pieces of configuration information that is stored inside the URL from time to time. Typical examples are: the theme in use, portal start up information and, in extreme cases, a session ID.

The BSP team provides a small BSP application to decode the mangling, see decode_url/default.htm.

The second question is “why” did we introduce this mangling? During the Web AS 6.10 development, a theme concept was developed, where specific objects in the MIME repository can be overwritten into different themes. For each BSP application, a cookie is set with all relevant information. However, this cookie is set exactly to the matching URL of the BSP application and wasnot sent by the browser when the MIME repository was accessed (/sap/something_else/…). The logic here is that you could have more than one active BSP application at the same time and each application must convey its own configuration information over different stateless HTTP GET requests to the MIME repository. As the same MIME repository URL was accessed, it’s not possible to set different cookies in different windows of the browser, locked onto the same path. The only reliable way was to encode information into the URL.

Encoding information into the URL has proved to be very useful sometimes, but at other times made life difficult. The current situation is that this coding is so deeply engrained into the BSP runtime, that for Web AS 6.20 and 6.40 it’s impossible to reconsider this situation. We must accept that URL mangling is done and that it cannot be switched off (or prevented). [For future work, this decision will be re-evaluated.]

How is URL Mangling Done?

The simple technique is that for the first request into the server, the BSP runtime sees that the URL is not in mangled form. In this case, an HTTP redirect is done, with the mangled URL as the new location. In the new URL, all relevant configuration information is encoded.

A small HTTP trace, with all irrelevant headers deleted, shows this process:

GET /sap/bc/bsp/sap/it00/default.htm HTTP/1.1  User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)  Host: ….wdf.sap.corp:50021     HTTP/1.1 302 Moved temporarily  content-length: 25  location: /sap(bD1lbiZjPTAwMA==)/bc/bsp/sap/it00/default.htm  content-type: text/html     GET /sap(bD1lbiZjPTAwMA==)/bc/bsp/sap/it00/default.htm HTTP/1.1  User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)  Host: ….wdf.sap.corp:50021     HTTP/1.1 200 OK  content-length: 336  content-type: text/html     ...content...

We see that the first request is received without URL mangling. The server answers with a redirect (HTTP rc=302) and supplies the new URL. On the next HTTP request the browser accesses the server with the new mangled URL.

You Can Hide, but You Cannot Run

In the last few days, we saw a question about disabling URL mangling. This is not possible. However, you may “hide” the mangling. Consider the following HTML code snippet: