Netscaler Knowledgebase

There are several different ways to issue a standard (302) redirect using the netscaler.  Prior to the responder module (introduced in V8 I believe), the most common method was to use a LB vserver to redirect the traffic.  An example of that configuration can be found here http://www.netscalerkb.com/netscaler_tricks_and_guides/url_redirection_using_content_switching-t25.0.html thanks to jmelika.

An alternate way is to use the responder module, which I actually prefer.  The reason I prefer the responder is because it keeps my list of LB vservers clean (not riddled with redirects), and it keeps all of my redirects in one place.  For someone like me, who has quite a few redirects, keeping my redirects organized and in one spot is a huge plus. 

The scenario is this, you want all traffic coming in on http://www.site.com to be redirected to https://www.site.com.  You could accomplish this with a simple responder policy and action.

First add your responder action.
add responder action responder_action1 respondwith '"HTTP/1.1 302 Object Moved\r\n" + "Location: https://www.site.com" + "\r\n"'
Next add your responder policy and bind it to the action created above.
add responder policy  responder_policy1 'HTTP.REQ.HEADER("Host").CONTAINS("www.site.com")'  responder_action1
Once you do this, you need you need to bind the policy.  Note that binding this type of redirect globally can create an endless loop, so I do not recommend using a global bind.  Instead, bind this policy to the appropriate HTTP vserver (either CS or LB).  When the policy is evaluated, the traffic will be redirected to your SSL vserver, avoiding the endless loop.

To bind your responder policy to your CS vserver you can use:
bind cs vserver YOUR_VSERVER_NAME -policy repsonder_policy1 -priority 1
Note that you might need to change the priority for your environment.

Using the same scenario as above, say you still want to redirect everything to HTTPS, however you want to preserve your URI string (i.e. http://www.site.com/landing will redirect to https://www.site.com/landing).  To preserve the URI path you can use this in your action: HTTP.REQ.URL.PATH

So your new action would look like this:
add responder action responder_action1 respondwith '"HTTP/1.1 302 Object Moved\r\n" + "Location: https://www.site.com" + HTTP.REP.URL.PATH + "\r\n"'
Jeremy

jlabadie,

I see that your redirection method redirects CS VServers.  When I tried binding it to an LB VServer, I received an error message:
ERROR: Binding invalid policy
When I tried binding it to a CS VServer, I got this error:

bind cs vserver cs_testfarm -policy responder_policy1 -priority 1
ERROR: Policy redirection not supported with NNTP

The interesting part is my cs_TestFarm is HTTP not NNTP:
show cs vserver cs_TestFarm
        1 virtual server:
1)      cs_TestFarm (IP_ADDRESS_HERE:80) - HTTP   Type: CONTENT
        State: UP
        Client Idle Timeout: 180 sec
        Down state flush: ENABLED
        Port Rewrite : DISABLED
        Default: lb_TestLiveFarm        Content Precedence: RULE
        Vserver IP and Port insertion: OFF
        Case Sensitivity: OFF

Any ideas?

Please keep me posted with how it works for you.

Responder operates before the CS policy is evaluated, or even for IC hit evaluation, so it is very early in the processing chain.  As such, it is very lightweight.  As a side-effect though, if you bind a responder to an LB vserver behind a CS, then the policy can't be hit, since the NS hasn't determined what LB vserver to use when it evaluates the responder policies.  On the NNTP issue, this was a bug in early 8.0 code revs, update to allow this to work properly.

The Oracle

Your confusion is understandable.  You can bind it globally, but for what you are mentioning, it still won't work, as the NS won't process the traffic on the right IP:port as "http" traffic, so the rewrite policy won't actually kick in.  This is the same issue as if you bind to an LB vserver that is down--because it is down, we won't syn-ack to a connection, so you won't get the responder policy kicking in.  For responder to work, we have to be processing the traffic as HTTP, THEN the policy can kick in.

The method of doing the LB with a backup is very commonly used, and works well.  The other way to do it is to use a CS vserver with no LB vservers bound--as a CS vserver by default doesn't go down (this can be controlled however), the responder policy will work bound to such a CS vserver.

The Oracle