The NetScaler can do A LOT – not just Citrix Access Gateway – the URL transformation, rewrite and responder engines are unbelievably powerful. One of the more common requests is to modify a URL so that it can be different for internal\external access or a different URL for a different set of users, even the ability to append a folder path to an existing host so that users don’t need to know the entire path – URL transformation is a perfect tool for this.
The most simple example is a URL transform to go from test.serioustek.net to demo.serioustek.net
This applies to mostly any version of NetScaler, but the navigation and screenshots will differ slightly. First, navigate to the AppExpert > Rewrite > URL Transform section of the NetScaler. Create a new transformation profile with any name you wish, then edit the transform action. These are the fields needed for this simple transform:
The Request URL From field is what the incoming URL should match, and the Request URL Into field is what the URL request will be transformed into – those are the request fields, but communications are two way – so the server is going to respond with the translated (demo.serioustek.net in this case) URL which will not match what the user entered. This is where the Response URL From field takes the response from the server and translates it back to match what the user entered, or the Response URL Into field.
Once You have a profile created, you must create and match a transform policy. For this example, I am using a simple hostname expression: HTTP.REQ.HOSTNAME.EQ(“test.serioustek.net”) – this policy can then be bound to a load balancing vServer or content switching vServer.
The protocol, hostname, path, and query can all be manually adjusted. The reqUrlFrom section supports Regex and has the ability to create variables ($1) based on word groups. The $1 – $9 variables can be used in the reqUrlInto section.
Lets look at another example where we are redirecting to a folder on the server, but the user does not see or know that it is going on. In this example, we are redirecting test.serioustek.net to demo.serioustek.net/Folder – here is the relevant transform action.
And we are now in the /Folder application on the ‘demo’ server when the user types ‘test.serioustek.net’
Now the fun part. Certain applications will respond with 302 redirects using absolute URLs in the location header field – Microsoft SharePoint is one of the most common to do this, and to be behind a NetScaler. So lets simulate that with some quick script.
This ‘Default.aspx’ is located at demo.serioustek.net/Folder/Default.aspx so when a user goes to test.serioustek.net they will be redirected to http://test.serioustek.net/Folder/Folder2. So what is the desired outcome? ‘test.serioustek.net/Folder/Folder2’ should be translated into ‘test.serioustek.net/Folder2’ since we are already translating ‘Folder/’.
You’re probably thinking that the URL transform policy will take care of this – not so much. You’ll get 404 because the resulting path at the server will be something like ‘demo.serioustek.net/Folder/Folder/Folder2’.
Why doesn’t the URL transform work? Because this absolute path came in a location header.
So what do we do about this? We use the NetScaler to rewrite the header to our needs. So let’s navigate to AppExpert > Rewrite > Actions and create a new rewrite action – see the below screenshot for explanation.
Create the associated policy – in this case, the expression I used is: HTTP.RES.HEADER(“Location”).CONTAINS(“test.serioustek.net”).
Bind the rewrite policy to the CSW or SLB vServer – note this is a Response policy as we are rewriting the response headers.
Now the headers should look like this:
And the page loads successfully: