Forum Discussion
CirrusURL/URI rewrite without changing in Client browser
I'd maybe argue that partitions aren't create separate logical BIG-IPs. It's more about building separate administrative domains on a single BIG-IP. Further, partitions can always access the /Common partition. To answer your question though, it depends on the level of isolation, but you should simply be able to point to the VIP in the oter partition,
virtual "/abc-app-dev/np-api-vip" or virtual "/Common/abc-app-dev/np-api-vip"You don't need SNAT to communicate between VIPs on the same BIG-IP.
Hi Kevin,
Thanks for your guidance. Here is what I figured out and it is working now. All happened due to your idea so thanks again.
IRule for same routing domain :-
when HTTP_REQUEST {
log local0. "Incoming request: [HTTP::host]:[HTTP::uri]"
if { [set match [class match -value -- "[HTTP::host]:[HTTP::uri]" starts_with datagroup_Name]] ne "" } {
log local0. "Datagroup match: $match"
## Get first URI path in client request
set FIRSTPATH [getfield [HTTP::path] "/" 2]
## Split match into host and path
set matchlist [split $match ":"]
set MATCHHOST [lindex $matchlist 0]
set MATCHPATH [lindex $matchlist 1]
## Replace FIRSTPATH with MATCHPATH (from full HTTP::uri)
set UPDATEDPATH [string map [list "/$FIRSTPATH" "$MATCHPATH"] [HTTP::uri]]
log local0. "Updated host: $MATCHHOST"
log local0. "Updated path: $UPDATEDPATH"
HTTP::host $MATCHHOST
HTTP::uri $UPDATEDPATH
virtual "/path/virtual_server_name"
}
}For different route domain
when HTTP_REQUEST {
log local0. "Incoming request: [HTTP::host]:[HTTP::uri]"
if { [set match [class match -value -- "[HTTP::host]:[HTTP::uri]" starts_with datagroup_name]] ne "" } {
log local0. "Datagroup match: $match"
## Get first URI path in client request
set FIRSTPATH [getfield [HTTP::path] "/" 2]
## Split match into host and path
set matchlist [split $match ":"]
set MATCHHOST [lindex $matchlist 0]
set MATCHPATH [lindex $matchlist 1]
## Replace FIRSTPATH with MATCHPATH (from full HTTP::uri)
set UPDATEDPATH [string map [list "/$FIRSTPATH" "$MATCHPATH"] [HTTP::uri]]
log local0. "Updated host: $MATCHHOST"
log local0. "Updated path: $UPDATEDPATH"
HTTP::host $MATCHHOST
HTTP::uri $UPDATEDPATH
pool pool_name
}
}
EmployeeOkay, so let's say you have a string datagroup that looks like this:
ltm data-group internal url_datagroup {
records {
www.blah.com:/blah {
data www.test.com:/test
}
www.foo.com:/foo {
data www.bar.com:/bar
}
}
type string
}I've intentionally added a colon ":" between the host and uri to make it easier to separate them later. So then you're matching on "[HTTP::host]:[HTTP::uri]" in the following iRule. If you have a match, you'll split the corresponding value into host and uri (split on the ":" to make a list object). You'll then, on separate lines, update the HTTP Host header and replace the HTTP URI.
when HTTP_REQUEST {
if { [set match [class match -value -- "[HTTP::host]:[HTTP::uri]" equals url_datagroup]] ne "" } {
log local0. "match = $match"
set matchlist [split $match ":"]
log local0. "match host = [lindex $matchlist 0]"
log local0. "match uri = [lindex $matchlist 1]"
HTTP::host [lindex $matchlist 0]
HTTP::uri [lindex $matchlist 1]
}
}You can now just add all of these HOST:URI patterns to a single datagroup. Now as I was mentioning earlier, it also depends on how static or dynamic the URLs are. For example, if the URI is statically "/foo", then the above works fine. But if /foo is just the start of the URI (ex. /foo/blah?this=that...), then the above won't completely address the problem. It'll change the HTTP Host, but then you need to do a string map to replace the portion of the URI while (presumably) keeping the rest. Example:
/foo/blah?this=thatwould be changed to:
/bar/blah?this=thatYou're doing all of this in the HTTP request. There's no URI, path or URI values in an HTTP response.
Point is, if you need to keep the user's browser on http://abc.com, you need to keep that traffic on the abc.com VIP. You can change the HTTP Host and URI on the abc VIP and forward the traffic to the pqr VIP, but there's no scenario where the abc VIP would change these values if the user was able to go directly to the pqr VIP directly.
CirrusHi Kevin_Stewart,
The data group which you shared can also be created in GUI right?
String would be www.blah.com:/blah and value for the string would be www.test.com:/test.
- Kevin_Stewart
Yes. This is the tmsh representation of a data group that I created in the UI.
- NathPras
Hi Kevin,
Thank your response. If the resource path is wild card (path (/xyz or /abc/12 or any instead of /test)) for say after www.blah.com/blah/anything can that be translated to www.test.com/test/(anything)
How this can be matched in data group creation?
Thanks,
Prasenjit
- Kevin_Stewart
Okay, so small modification. This assumes the path to be replaced is the first path in the URI:
when HTTP_REQUEST { if { [set match [class match -value -- "[HTTP::host]:[HTTP::uri]" starts_with url_datagroup]] ne "" } { ## Get first URI path in client request set FIRSTPATH [getfield [HTTP::path] "/" 2] ## Split match into host and path set matchlist [split $match ":"] set MATCHHOST [lindex $matchlist 0] set MATCHPATH [lindex $matchlist 1] ## Replace FIRSTPATH with MATCHPATH (from full HTTP::uri) set UPDATEDPATH [string map [list "/$FIRSTPATH" "$MATCHPATH"] [HTTP::uri]] log local0. $UPDATEDPATH HTTP::host $MATCHHOST HTTP::uri $UPDATEDPATH } }
