Forum Discussion
CirrusIrule Vs rewrite - FQDN hostname
MVPMr__T So a few things stand out to me. First is that you don't want a redirect you would like a rewrite but in your rewrite it looks like you want to add on a port at the end of the host which shouldn't be necessary because your pool member should be listening on that port already. The last is whenever they hit just "/" as the URI do you want to redirect them to a specific path? So as an example of how I believe this works.
User requests https://appname.domain.com/
F5 responds with a redirect to https://appname.domain.com/something/something/something/etc/etc/etc.html
User now requests https://appname.domain.com/something/something/something/something/etc/etc/etc.html
F5 rewrites appname.domain.com to longappname.com
F5 sends request to server on https://longappname.com/something/something/something/etc/etc/etc.html
Response comes back from server and F5 rewrites longappname.com to appname.domain.com
F5 sends response back to client for https://appname.domain.com/something/something/something/etc/etc/etc.html
If for some reason I did not understand this correctly can you provide additional information as to how it has to function?
Mr__THi Paulius,
The long URL is what the app has hardcoded and will only respond to that URL. So my goal was to make sure the client only sees the frienly name after the redirects happen. I tried rewrite policies but the IRule seems to be the way to go. The redirect to he long URL works fine, but they dont want to see the servername rather FQDN.
Does this make sense?
- Mr__T
Hi Paulius
Thanks for the reply.
When i tried the re-write it did not work as exected.
User request https://FQDN.
The backend server/pool member is expecting https://servername:port/something/something. and wont respond to https://FQDN
I need the browser to always return https://FQDN and not the https://Servername
Does this make sense?
- Paulius
Mr__T If your pools have multiple pool members I do not believe this will be possible because you will require mapping a single FQDN to multiple server names depending on the pool member that you are sent to. Your best bet here would be to work with the server/app admins to see if they have a way of changing what they expect for the host and path. Typically all of this can be done at the server level instead of performing a bandaid at the F5 which in some cases such as yours will not work because of the single FQDN to many names issue.
- Mr__T
Only 1 server in the pool. We tried to get the app owners to correct this at the application but they could not.
So the server is expecting https//:servername:8443/etc/ etc/etc/landingpage. Cosmetically, the app owner does not want to see unfriendly name.
