Jump to content
Welcome to our new Citrix community!

Redirecting request and change url address

Recommended Posts

Hi Experts,


I have tried to find solution on forum but I am bit confused if I need to use rewrite feature to URL Transformation. I haven't used either of these in past and it doesn't seems straight forward thing.


We have a web page "myservers.domain1.com" which is a legacy report listing our servers, we have recently configured same report on o365 PowerBI and web page is called "app.powerbi.com/....."


I have configured responder to redirect request coming to "myservers.domain1.com" to "app.powerbi.com/....." report which is working fine however we dont want users to see url address as ""app.powerbi.com/....." because it is confusing and hard to remember. We want users to see original url that is  "myservers.domain1.com". Is it possible to to this in Netscaler?



Link to comment
Share on other sites



If you old url using the same port etc .In this case you can try to update your DNS. So I believe you already have VIP on the NetScaler and just update the DNS enetry.

I think this is simple solution if you have no other requirements.


Or try this as Carl suggest here


Remove the VIP from the current LB vServer A (uncheck the box next to Directly Addressable). You might to delete the vServer and recreate it. On 10.5, change the IP Type to Non Addressable. LB vServer B can also be non addressable.


Create a Content Switching vServer and assign it the same VIP normally accessed by users.


Create a CSW Policy that looks for /page and send those requests to the LB vServer B.

Bind LB vServer A as the Default LB vServer.

Requests for /page go to LB vServer B, all other requests go to LB vServer A.





Link to comment
Share on other sites

The trick with URL transform is to have a good idea of the client-side request format/patterns you are looking at and what the server side pattern will be.

This way you can figure out the client to server request time transformation that you need AND the server to client response time transformation (to affect the patterns of urls in response body) to return to the user, so you can maintain that "client-side view" vs "server-side view".


The other part, is knowing about regex to do it.


Generally, I would start about making a list of 3 (or even) 5 examples depending on the scenario of the client side url pattern(s) and their corresponding transform server side. And this usually helps me see all the patterns we need to account for. In your  case, if its just teh FQDN and the port and no path changes, it may not need that much to change.


Next plan out the lb requirements and then the URL Transformation. 


If you don't have any port changes in the fqdn, this should be a straightforward regex:

Transform client requests: 

http(s)://myservers.domain1.com<path and query>   into http(s)://app.powerbi.com<path and query>

So we need to identify the request time client-side pattern and how to parse it into the server-side pattern.  It uses a type of reg-ex backreference, so any pattern in the original URL you want to preserve or move in the server side url, you need to enclose in parantheses so it can referenced as $1, $2 etc in the server side transform.


REQUEST Transform:  client to server
http(s?)://myservers[.]domain1[.]com(.*)            into     http$1://app.powerbi.com$2


RESPONSE Transform:  server to client (this will change full urls in response body returns to client):

http(s?)://app[.]powerbi[.]com(.*)                  into         http$1://myservers.domain1.com$2



You can also bind a responder policy to the lb vserver, if you see any clients using the old URL client side and use it to redirect app.powerbi.com to myservers.domain1.com, since responder will kick in before rewrite, it should correct in bad urls to begin with.  I think your responder policy is backwards as you want users to redirect from "wrong" url to your preferred client-side pattern (which I read as myservers.domain1.com).  Then the transform will map public url into private url format and rewrite the return urls from private url into public url.  If I misinterpeted your goal, update the thread.




Link to comment
Share on other sites

Its too vague to be able to troubleshoot. 

Give some examples (plural) of your request time URL patterns that you want to transform into the actual/server side patterns and vice versa.

You can change the fqdn's for examples and paths in the examples, but to troubleshoot we'll need to see some idea of how the regex is being parsed to understand the issue.


For your transform policy expression, remember that contains is case-sensitive. So try http.req.hostname.set_text_mode(ignorecase).contains("...") to see if it makes a difference.


Remember, that the "request" time FQDN is what the USER sends to the VIP that we need to transform INTO the backend/actual format.

If users are using the "old"/internal name publicly, then that would be a SEPARATE RESPONDER redirect from "old name" to "new name".


What you have in your policy above for the transformation is something like:

Transform url (from client):  https://serverlist<stuff>... INTO url (to server/actual)  https://app.powerbi.com<stuff>  (again not enough of the regex to figure out if something else is wrong.


With the (.*) expression YOU usually do not "want" a leading "/" as you want to the .* to catch a URL that terminates with no slash, "/" only, or "/and stuff". In some cases you may create a rewrite that might be "//<stuff>"; not certain because I can't tell the regex you are using.  It looks like you are adding extra directories before tacking on the path, but I can't see if you have a $1 or not specified...so possibly a regex issue.


If you are still having issue, use the LOG ACTION and enable custom logging in syslog to write out some of your urls via log to see if they are working or not;   or switch to simple rewrites to test elements of the rewrite to see if it works as expected.

Are you getting policy hits and failed transforms or no policy hits.

















Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...