URL Rewrite

jefftuckerbofajefftuckerbofa Posts: 104

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

  • williammccuskerwilliammccusker Posts: 528 ✭✭✭

    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?

  • jefftuckerbofajefftuckerbofa Posts: 104
    edited August 26

    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.

  • williammccuskerwilliammccusker Posts: 528 ✭✭✭

    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?

  • williammccuskerwilliammccusker Posts: 528 ✭✭✭

    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?

  • jefftuckerbofajefftuckerbofa Posts: 104

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

  • jefftuckerbofajefftuckerbofa Posts: 104

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

  • jefftuckerbofajefftuckerbofa Posts: 104

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

  • williammccuskerwilliammccusker Posts: 528 ✭✭✭

    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?

Sign In or Register to comment.