Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

URL Rewrite

Is there an easy way to rewrite the URL of a request using one of the available tools? I have a situation where I'd like to drop the first segment of the /context. For example:

original path: /foo/bar/operation

Tool rewrites the path to: /bar/operation

Thanks,

JT

Comments

  • williammccusker
    williammccusker Posts: 535 ✭✭✭

    Hi,

    I have some questions that will help me understand this use case. Is the desire to change the URL and redirect a request to somewhere else? For example would it make sense to have a message proxy listening on /foo/bar and then the outgoing URL could be set to just /bar which would rewrite it. Or does this rewriting need to happen somewhere inside the processing of the request by a responder?

  • jefftuckerbofa
    jefftuckerbofa Posts: 117
    edited August 2021

    I have thought about extracting and rewriting the path and using it in a Message Forward tool, however we're building these VAs via the REST API and it doesn't seem to have full support for those types of tools. Using the REST API is a requirement for the framework we have set up for allowing groups to build their responders.

  • williammccusker
    williammccusker Posts: 535 ✭✭✭

    Hi,

    I think I understand the challenge. For users connecting to the virtual assets each one has their own special group name so that messages can be routed to responders created specifically for those users. A general message proxy can be created for this use case that listens on a shared endpoint and user's configure their applications to connect using their group name.

    The challenge is that when setting up a secondary connection for that shared endpoint the group name gets sent to the live service. The live service doesn't accept the paths with the group names so the request fails.

    The current work around is what you mentioned, explicitly setting up proxy connections for each group name so that the when the connection failures and goes to the secondary the group name gets removed.

    This workaround is not ideal because of the number of group names means configuring a significant number of additional connections.

    Would you say that is an accurate description of the issue?

  • williammccusker
    williammccusker Posts: 535 ✭✭✭

    Hi,

    Was a comment deleted? I thought I saw a comment that described listen paths and configurations, etc. but now I don't see it.

    One more question, when rewriting the URL does only the group name to be removed or do addition leading path segments need to be removed?

    For example would a request path look like this?
    /context/groupA/resource/path

    And the desired rewritten URL to the secondary would be this?
    /resource/Path

    Or is only the groupA part suppose to be removed?

  • jefftuckerbofa
    jefftuckerbofa Posts: 117

    yeah I went to make an edit and it got deleted somehow

  • jefftuckerbofa
    jefftuckerbofa Posts: 117

    Yes, you described the issue perfectly. The only change needed is to strip off the /groupA portion of the endpoint.

  • jefftuckerbofa
    jefftuckerbofa Posts: 117

    I also thought about splitting the traffic by port, but that still requires me to maintain a copy of a proxy for each group.

  • williammccusker
    williammccusker Posts: 535 ✭✭✭

    Hi,

    Yes, splitting the traffic by port or by adding the group to the listen path is going to mean multiple configurations to manage.

    I don't have a solution thats better than managing the multiple listen paths today but I can see that this would be a valuable use case that could be better supported. The general idea makes a lot of sense of having a common listen path followed by a dynamic path segment and then wanting that dynamic path segment to either be sent or removed.

    Could you contact Parasoft Support and formally request this feature?