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:
Thanks for a very interesting post. Interesting food for thought about the URL mangling indeed. I'm a purist at heart so am often persuaded to go down to a level beneath BSPs to write my web services to avoid the mangling (using frames is not a workaround that appeals - anyone in our group who even thinks about using frames is banished from the office for the day :-).
I can't find the decode_url BSP app in my Linux WAS 6.10. Where / from when is this available? Just curious.
I decided to roll my own - and wrote about it here:
BSP: Mangled URL Decoder
I found that I get new session IDs now even for an already running stateful application when I call it in another frame with the normal unmangled URL.
After analyzing the problem I think this is because the mangled URL is different now, the URL decoder shows the difference: There is a new parameter (w) (for window ID) that gets created out of a timestamp. The session ID cookie (sap-contextid) is stored with the path of the mangled URL. Therefore it is not accessible for the second frame any more that has a different mangled URL due to the new window id parameter.
since this paremeter (w) caused many problems with frames, applets, etc. it was finally desided to abandon this parameter.
There is a correction note 857476, which removes the 'w' parameter from the URL.
See here http://service.sap.com/~form/handler?_APP=01100107900000000342&_NNUM=857476
This information is extremely helpful, thank you.
You mention that in "extreme cases" the session ID is encoded into the mangled URL. This seems to be happening to me all the time. Can you tell me what the "extreme cases" are and if there is any way to get around it?
It there a way this will also work for the Integrated ITS?
We are using the Reverse Proxy and the SAP Web Dispatcher and it still mangles the URL.
10:11:59 948 0.000 1606 GET 302 25 text/html; charset=utf-8
The information in the URL should not be generated in the first place.So encrypting will not help ,it must be readable by the browser,
and if it is it is also readable for a hacker.So we need to find some way to short the URL and also remove the version details.
It's possible to short the URL in some way?
We're baffled by this URL mangling. We've been using ITS for a decade and it's the first time this issue has hit us (after a recent service pack). This URL mangling basically makes our application unbookmarkable. Users bookmark after logging in and don't realise they've bookmarked a session. Next time they launch the bookmark they get a session timeout error. How can this be avoided?
btw. your HTML snippet (at the end) has disappeared. Could you repost it?