Forum Discussion
David_Barrett_2
Nimbostratus
NimbostratusHiding redirects
I have a question for writing an iRule on a 9.x
The application people would like the Big IP to take one URL and redirect to another URL or specify a URI under the first URL or redirect to a second URL altogether.
The trick is that the place we’re redirecting to must still “think” that the request is coming from the original URL and the users’ browser should still show the original URL
Example
Will need an 80 to 443 redirect…
http://training.company.com goes to https://training.company.com
and
https://training.company.com/sales needs to go to https://sales.company.com but still “think” its coming from https://training.company.com (some sort of hidden redirect?)
and/or
https://training.company.com/device1 needs to go to https://device.company.com but still “think” its coming from https://training.company.com
So, how do I maintain the original URL on the user’s browser while still redirecting to a new URL?
One more item to complicate things is that the Big IP houses the SSL cert for the training site.
Thanks for your time…
- This is actually what we term "rewriting" the url as opposed to "redirecting" it.
On an incoming request you can modify both the host header and/or the uri of the request.
To modify the host header, use the command:
where $value represents the new value for the host. However, modifying the host maybe unnecessary as the BIG-IP is really choosing the host from a collection of pool members based on the load-balancing method. Usually, the Host header is used merely to record what host the original request was targeting. It's also used for virtual hosting so that the web server can sort out what host the request was targeted to. Since the BIG-IP is usually making this decision through the pool member selection you may not even need to change the Host header.HTTP::header "Host" $value
To modify the uri, use the command:
This will change the uri of the request to the one specified by $new_uri.HTTP::uri $new_uri
The biggest caveat to "rewriting" the uri is that any references in the returned content will not necessarily be modified. If the server takes care to always use relative references, then things generally will work out ok. However, if the content contains absolute references, then the client will either eventually discover the new uri, or it may not even function as the new uri may not be accessible by the client. To correct for this the content can also be searched and replaced. We have a couple of methods for doing that but they all add a bit of complexity to the problem. One approach is to buffer the response and then search and replace it. This is often the easiest solution because any changes to the content likely need to have the Content-Length updated. The Content-Length header is at the beginning of the response and so you just can't search and replace without buffering the response since you need to know the new resulting length before updating the Content-Length header. Another approach is to have the BIG-IP transform the request to a chunked response and then use the stream profile to search for and replace any transformed uris.
Hopefully this helps!
