Forum Discussion
Shadow
Cirrus
CirrusiRule resulting in too many redirects
I have two requirements with my virtual server. 1. A redirect to /pc/service/SSOLogin 2. 24 hour persistence based on the JSESSIONID cookie in the request header. The first one was accomp...
ShadowCirrus
CirrusI rewrote the iRule to add the logic that Lucas_Thompson referenced to determine when I need to redirect. I can't find anything wrong with the code. However, I get ERR_CONNECTION_RESET.
For added information, I am using this iRule in conjunction with Universal persistence.
The new code is below.
when HTTP_RESPONSE {
## PERSISTENCE
# If the JSESSIONID exists, we'll pass the cookie along
if { [HTTP::cookie exists "JSESSIONID"] } {
persist add uie [HTTP::cookie "JSESSIONID"] 86400
}
## REDIRECT
# Check if the request path is not "/pc/service/SSOLogin"
if { $url_redirect } {
# Redirect to the new URL
HTTP::redirect $new_url
}
}
when HTTP_REQUEST {
## PERSISTENCE
# If the JSESSIONID exists, we'll maintain that persistence
if { [HTTP::cookie exists "JSESSIONID"] } {
persist uie [HTTP::cookie "JSESSIONID"]
}
## REDIRECT
# Check if the request path is already "/pc/service/SSOLogin"
# If so, set the url_redirect to false. If not, set it to true.
if { [string equal [HTTP::uri] "/pc/service/SSOLogin"] } {
set $url_redirect 0;
} else {
set $url_redirect 1;
# This grabs the base URL from the incoming request
# For example, https://my.site.com/some/path the base_url is set to https://my.site.com
set base_url "https://[HTTP::host]"
# Defining the new path
set new_path "/pc/service/SSOLogin"
# Construct the new URL
# For example, https://my.site.com/pc/service/SSOLogin
set new_url "$base_url$new_path"
}
}
- Lucas_Thompson
Employee
Super! It sounds like you're able to test these changes rapidly and have a good test environment.
A few pointers while you're developing code:
1- Keep a ssh session open and watch the log file output from ```tail -f /var/log/ltm``` while you're working on it. RSTs and other misbehavior will be easy to spot. Any syntax error or unreferenced variable will cause BIG-IP to RST the connection and produce a log message.
2- Because iRules don't really have a debugger, you have to use the "debug by printf" method. This means peppering your code with log statements during development. Like, before EACH command you run something like this:
log local0. "about to set persist entry on [HTTP::cookie JSESSIONID]"
persist uie [HTTP::cookie "JSESSIONID"]
or
log local0. "about to send 302 redirect to $new_url"
HTTP::redirect3- If you're "done" inside an event and want to finish up, you can use the ```return``` command to exit the event. It seems like in your code that you want to ```persist``` OR ```rerdirect```, but not both.
4- The ```set``` command sets variables. Once set, variables are generally available later on in the same flow, but you should always check them first to make sure the data you expect is there. You can use the ```info exists``` command to achieve this. See this discussion for more in-depth about that: BIG-IP : iRule test that variable exists and has certain value | DevCentral
