The requirement is Client access with url : https://abc.com/x/* the request comes to f5 and f5 removes the "/x" in uri keeping all other parts of uri same as : https://abc.com/* and then forward to backened member serever 184.108.40.206 on port 44500.
We have tried using the Policy :
- first user gets the backened page on https://abc.com/x/* as expected there is option to login in the page, when the user enters the credentials and submit, it starts connecting to backened url https://abc.com/* directly from client browser making it fail.
Configuration done in f5 :
Match condition : HTTP URI full string contains '/x' at request time.
In developer tools when we see the response from server in client browser, it does show the frontend host as expected, but we see the server has given the backened uri as actual without including the "/x" which we removed.
Even the page that it dispays for login was not loaded properly missing images in developer tools shows that image was not able to load as it tried with direct uri from customer browser to load it eg https://abc.com/image1 rather than https://abc.com/x/image1.
@Abhi-netdive The reason you're having this issue is because the server does not know that the client made a request to a path with "/x/" so when it sends the literal path to the client to retrieve the images the client searches for that literal path. What is the reasoning for not allowing the client to use the real URI path and it must use the "/x/" in the path? I don't believe you will be able to get around this without editing the response from the server and adding in "/x/" to every response that it sends to the client which will complicate the configuration which will cause delays when troubleshooting.
The /x is used as identifier to take the connection the required server in backened. Like /directory is common in all server if we want server1/ directory to access from outside, then /x is added in url to use it condition to match and then forward to server 1.
Please suggest how can we edit the responses urls.
If there is way to include in the response going back "/x/" it would be able to resolve from client.
the clean and ideal solution is asking the app developer to only use relative paths