Forum Discussion
Redirect both host and path via iRules
I"m fairly new to using iRules and writing redirects, but currently I have a redirect in place that does http to https redirect via the switch parameter for different host names, see below.
when HTTP_REQUEST {
switch -glob [string tolower [HTTP::host]] {
"abc.com" -
"www.abc.com" {
HTTP::redirect http://abc.123.com
}
"def.com" -
"www.def.com" {
HTTP::redirect https://www.def.com[HTTP::uri]
}
default {
reject
}
}
}
But now, I need to add an uri/path redirect for for example:
def.com/example to https://www.def.com/site1/example
What would be the best way to accomplish this?
6 Replies
Hi Daniel,
you can add leadings parts whenever you want...
when HTTP_REQUEST { switch -glob [string tolower [HTTP::host]] { "abc.com" - "www.abc.com" { HTTP::redirect http://abc.123.com } "def.com" - "www.def.com" { HTTP::redirect https://www.def.com/site1[HTTP::uri] } default { reject } } }Note:
always starts with an[HTTP::uri]
, so you don't need to explicitly add a slash./Cheers, Kai
- Kevin_Stewart
Employee
If it's just a few conditions you could reasonably nest switch statements:
when HTTP_REQUEST { switch -glob [string tolower [HTTP::host]] { "abc.com" - "www.abc.com" { HTTP::redirect http://abc.123.com } "def.com" - "www.def.com" { switch -glob [string tolower [HTTP::uri]] { "/example*" { HTTP::redirect "https://www.def.com/site1/example" } default { HTTP::redirect https://www.def.com[HTTP::uri] } } } default { reject } } } - Daniel_Ma_23954
Nimbostratus
Thank you both for the suggestions. I'm going to try the nested switch statement later tonight. Will let you guys know if I encounter any issues.
- Daniel_Ma_23954
Nimbostratus
The nested switch statements seems to be working correctly, as all the conditions are redirecting to the correct https URLs when it's a http request.
However, in my case, I also need to redirect those same conditions when it's a https request. Below is what I have so far:
when HTTP_REQUEST { switch -glob [string tolower [HTTP::uri]] { "/example" { HTTP::redirect "/site1/example" } "/example2" { HTTP::redirect "/site2/example" } default { reject } } }In the above code, I'm having some issues with the default. I've tried using reject and leaving it blank, neither seems to work properly. The default should just go to the main site. How can I accomplish this?
Thanks again for the help
- Daniel_Ma_23954
Nimbostratus
So, I ended up removing the nested switch statements, keeping just the host redirects.
For the uri redirects, I went with the method in the following link, https://devcentral.f5.com/questions/uri-redirects-24892 and things are working for me.
Hi Daniel,
the
"default" or[switch]
"else" conditions are both optional. You can either leave them empty, but you can also remove the default/else conditions if you like. The outcome would be exactly the same. But I personaly tend to keep those condition for better visibility and add a meaningful comment to it...[if]when HTTP_REQUEST { switch -exact -- [string tolower [HTTP::host]] { "abc.com" - "www.abc.com" { HTTP::redirect http://abc.123.com } "def.com" - "www.def.com" { switch -exact -- [string tolower [HTTP::uri]] { "/example" { HTTP::redirect "/site1/example" } "/example2" { HTTP::redirect "/site2/example" } default { Forward to default pool } } } default { reject } } }Note: You should use
only if you need to match certain single charcter wildcard-glob
or general wildcards?
. If matching conditions without wildcards, then*
would be the better choice in terms of performance.-exactNote: If you need different rulesets for HTTP and HTTPS access, then it would be more effective to have two independent iRules. Well, if the differences are not that much, then you could also include contitions to make decission based on the accessed protocol, but its those conditions add a slightly overhead to your CPU. But on the otherhand may be reduce the administrative overhead to maintain the two almost identical iRules.
Note: Your Datagroup approach should be fine. Datagroups are easier to manage for iRule startes, since they don't require you to have a deep iRule knowledge for daily changes.
Note: When testing/changing iRules, then always keep in mind, that iRules changes are only become effective for new TCP connections. I guess the trouble of your "default" condition experiments may be the result of keep- alive TCP connections?
Cheers, Kai
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
