Layer 7 API Management

Expand all | Collapse all

Issue with Host Value

Jump to Best Answer
  • 1.  Issue with Host Value

    Posted 07-05-2019 10:22 AM
    Edited by Giridharan S 07-05-2019 10:30 AM
    As per docs of CA API ${request.url} returns only the host name portion of the URL. Say for example, if the request URL is https://10.4.9.41:8443/login, then request.url should return 10.4.9.41. This was the behaviour till yesterday. But suddenly, values like localhost:7000, localhost:8000 got popped up. I believe the UI application is hosted locally. Even in that case, the target URL for the application has to be something like https://10.4.9.41:8443/** only then it can reach out to CA Gateway.

    I am quite confused with the behaviour. can someone tell me is there any configuration level changes are required for this?

    Thanks in Advance!

    ------------------------------
    With Regards,
    S Giridharan
    ------------------------------


  • 2.  RE: Issue with Host Value

    Posted 07-18-2019 02:51 PM
    The Gateway won't change behaviour all on it's own, so if you are seeing a change then it was likely modified somewhere. You can check your audit logs for who and what may have done it if you happen to know the date it occurred and still have the audits available. I would look to confirm that you are still using the ${request.url} and not the other context variable which exposes the full URL. Do you only see that behaviour when it states localhost or for other addresses too? Have you installed any CRs or anything like that recently that may have impacted the behaviour?


  • 3.  RE: Issue with Host Value

    Posted 07-21-2019 02:24 PM
    Hello Dustin,
    I just re confirmed that {request.url} is still being used in our proxies. This behavior is only for a particular customer from a different zone.



  • 4.  RE: Issue with Host Value
    Best Answer

    Posted 07-22-2019 02:34 PM
    If it's only from one particular customer from a "different zone" then perhaps there is something else such as a global policy that that particular customer's requests filter though in that policy logic? In other words, is it possible that the assertion you think is auditing the data isn't actually the one being executed when it's showing the unexpected data? Maybe it's somewhere else in policy logic outside of that primary policy. Just a guess, something to look into.

    ------------------------------
    Senior Technical Support Engineer
    Broadcom
    ------------------------------