Implementing Server Portals - TWURL (two way URL rewrite)
search cancel

Implementing Server Portals - TWURL (two way URL rewrite)


Article ID: 166586


Updated On:


Advanced Secure Gateway Software - ASG ProxySG Software - SGOS


Implementing server portals for a Reverse Proxy.

You want help implementing server portals

How do I set up a two way URL rewrite (TWURL)?


In the section on "Transformer Definition" in the below linked "SGOS Policy Best Practice Guide", find the following explanation of the "url_rewrite" definition:

SGOS Policy Best Practice Guide

A url_rewrite definition defines rule for rewriting URLs in HTTP responses. The URLs are either embedded in tags within
HTML, CCS, JavaScript, or ASX documents, or they are contained in HTTP response headers. In addition to rewriting
URLs, you can also rewrite arbitrary JavaScript.

This transformer takes effect only if it is also invoked by a transform action in a define action definition block, and that block
is in turn called from an action() property.

For each URL found within an HTTP response, a url_rewrite transformer first converts the URL into absolute form, then
finds the first rewrite_url_substring or rewrite_url_prefix statement whose server_URL_substring matches the
URL being considered. If such a match is found, then that substring is replaced by the client_url_substring.


The visual policy manager (VPM) has not support for TWURL; you will have to use CPL.

A server portal provides controlled access to a web server or a collection of web servers.

When a ProxySG is configured as a server portal, it performs two-way URL rewrite between a set of client URLs and a set of server URLs.  The client URLs are the ones used by client workstations to access web pages behind the portal.  The server URLs are the ones understood by the web servers behind the portal.

When the ProxySG receives a request from a client for a web page that is inside a server portal, it rewrites the requested URL from client form to server form, then it sends the rewritten request to the server.  When the server sends back a response, the ProxySG rewrites URLs inside the response from server form back to client form.

When you set up a server portal, you must decide what the client URLs look like, and what the corresponding server URLs look like.  In the following example, the client URLs have the form

and the server URLs have the form

This example uses client URLs beginning with "https", which means you have to configure service port 443 as an HTTPS port.  This configuration is outside the scope of this KB article.

Here is a policy that implements the example:

define url_rewrite P
rewrite_url_prefix "" ""

define action portal
rewrite(url, "*)", "$(1)")
transform P

define action force_uncompressed
delete( request.header.Accept-Encoding )

url= action.portal(yes)


Here's how this policy works:

  1. The initial <Proxy> layer performs a two-way URL rewrite on the request if the request matches a client URL for the server portal.
  2. The <Cache> exists because the response URL rewrite does not work if the response is compressed.  To work around this limitation, we need to modify the request to tell the server not to compress the response.  We have to put this action into a <Cache> layer, not in a <Proxy> layer, because we want to force an uncompressed response in the case where the document is being fetched for the purpose of freshening the cache, as a result of the adaptive refresh algorithm.  And refresh requests do not evaluate <Proxy> layers.
  3. The define url_rewrite statement is used to specify the client and server URL schemes, but it is only used for response URL rewrite.  The "rewrite_url_prefix" command specifies the prefix of a client URL, followed by the prefix of a server URL.  In a complex server portal, you can have a sequence of these commands, and the first one that matches the server URL being rewritten will win.
  4. The "define action portal" statement contains two actions.  The first action rewrites the request URL from client form to server form.  The second action rewrites URLs in the response from server form to client form.
  5. The "define action force_uncompressed" statement contains a single action which deletes the Accept-Encoding request header.  This tells the server to not send a compressed response.