Using Web Dispatcher 7.2 HTTP handlers
In this blog I will focus on the Web Dispatcher 7.2 together with the portal and the new feature of manipulating URLs by making use of the HTTP handlers. I will focus on the redirect URL manipulation and therefore on the redirect handler (SAP Help).
The redirect handler forwards the HTTP request from the browser to another location (HTTP redirect). Redirecting the browser was already possible in earlier versions of Web Dispatcher (the URL prefixes the ICM uses for the redirect are determined by the icm/HTTP/ redirect_<xx> parameter), but in 7.2 it gained a new feature: now you can define the HTTP code. In versions < 7.2 the browser requested a resource and the Web Dispatcher sent back a HTTP 302 or 307, depending on the HTTP protocol used by the browser. If it is a HTTP 1.0 request, the answer is a 302, if it is HTTP 1.1 (keep alive) it is 307.
As this serves the basic needs of applying the redirect, it isn’t a permanent redirect. Temporary or permanent redirects are more or less treated equally by browsers. A Google search revealed that it looks like Google Chrome, Firefox 3.5 and IE9 are may cache 301 (see here (http://en.wikipedia.org/wiki/HTTP_301) for general information on 301 cache) while other browsers will look up the URL with every request.
To proof that the Web Dispatcher is not a full reverse proxy only requests can be manipulated. As the name of the operation suggests, only the request and not the response are treated by Web Dispatcher. The Syntax for the redirect handler is:
RegRedirectUrl / http://server.domain:8080/default.html (CODE=permanent)
Where the code value can be: permanent, temp or seeother.
Example
Lets say you have stored a document in your KM and changed it (name, location), but you cannot change all the links that refer it (or create a link in the KM). The original document is stored here:
http://server:port/irj/go/km/docs/documents/Test/original.txt
and the new one here:
http://server:port/irj/go/km/docs/documents/Test/newfile.txt
In the KM you can create a link from the original location to the new location, but this implies that you create a link in the KM. Letting the Web Dispatcher handle the redirect means that the actual request to the old file never will reach the KM and portal. The Web Dispatcher will intercept the request and send back the redirect. In Web Dispatcher 7.0 the redirect rule would be:
icm/HTTP/redirect_0 = PREFIX=/irj/go/km/docs/documents/Test/original.txt, TO=/irj/go/km/docs/documents/Test/newfile.txt
When the user accesses the file the Web Dispatcher and the browser will treat the request as shown here:
To change the 307 to a 301 it is necessary to make use of modification actions. Modification actions allow a complex alteration of HTTP requests / headers. For modifying the request to be a permanent redirect, you need to follow the steps outlined here. The main steps are:
1. |
Create an action file. This file contains the (regular) expression that should be applied. A For my example I named the file actionfile.txt and the content is just 1 line:
|
2. |
Activate the modification actions in the profile file of the Web Dispatcher by setting the parameter icm/HTTP/mod_<xx> In my case, the syntax is:
|
When the users tries to access the original.txt file the Web Dispatcher sends back a 301 and the browser requests the new file:
Result
How about cache?
1st request: Both files are access the first time and therefore loaded.
2nd request: The 301 gets called again, while the newfile.txt is loaded from cache.
Thanks for the blog - interesting reading.
Ondrej
Hi Tobias
Thanks for the Blog – there is truly interesting content and solutions that can be further used in our projects. Regarding this particular post, we have used HTTP Handlers to redirect .CSS requests from Design Data Applications to KM in order to gain more flexibility when changing the look and feel of the Portal. Regarding this kind of change, do you think it is possible to have the Theme .CSS Files in KM without losing Theme Editor Functionalities?
We did some research on Theme Editor and we were able to realize that the theme editor is based on “XML Files” that control the output and declarations of .CSS values. We have made a Proof of concept example in order to generate custom look and feel themes with Theme Editor. This seems to work(the development process was slow because we had to manually create the xml file structure) but when the theme is transported to the Productive Portal these parameters are unknown and the theme gets rendered with SAP values only.
Do you have any suggestion on this issue? Would you think it’s possible to change the Theme Editor in order to generate the files to the KM repository we are using?
Thanks
For the portal theme, you may check my other blogs:
http://scn.sap.com/community/portal/blog/2011/05/12/customizing-the-sap-portal-theme
http://scn.sap.com/people/tobias.hofmann/blog/2011/05/02/caching-the-sap-portal-theme
http://scn.sap.com/people/tobias.hofmann/blog/2010/11/30/km-cache-for-portal-application-files
These also cover how to use the KM for caching / storing the theme files. Basically, you use the theme editor to create the theme / files and then copy them to the KM and use the web dispatcher to redirect the browser.
Everything beyond that should be done IMO on the generated files.