starred/WireMock.Net-wiremock
1
0
Fork 0
mirror of https://github.com/wiremock/WireMock.Net.git synced 2026-01-11 22:30:41 +01:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

Can I preserve Mapping title and matchers for proxy response? #455

New Issue
Closed
opened 2025-12-29 15:24:11 +01:00 by adam · 14 comments
adam commented 2025-12-29 15:24:11 +01:00
Owner
Copy Link

Originally created by @steven-nelson-olo on GitHub (Sep 28, 2022).

Originally assigned to: @StefH on GitHub.

Hello.

I use a third party SOAP service that I've been told I run tests against too often. I was hoping to use WireMock to proxy and record these requests. Then I'd like to use the recorded mappings as stubs going forward. To proxy and record the initial set, I use something like this:

    server
        .Given(Request.Create().WithPath("/*")
        .WithBody(new RegexMatcher("<RequestType>Auth</RequestType")))
        .WithTitle(rule.Name)
        .RespondWith(Response.Create().WithProxy(new ProxyAndRecordSettings
        {
           Url = proxyTarget,
           AllowAutoRedirect = true,
           SaveMapping = true,
           SaveMappingToFile = true,
        }));

Because it is a SOAP service, all the requests use the same URL. The request primarily differ on the body contents. Currently when I run these requests, it seems like a new mapping is creating, using the path and method to create a new title. Since the path and method are the same for each request, each request overwrites the one before it. It also seems that the regex matchers that were specified in the original mapping are being discarded in favor of matching the url, path, headers, and an exact match on the body of the request.

If that understanding is correct, is there a way to work around this behavior to preserve the original mapping? If there isn't a work around, I'd like to submit a PR. In it, I'd try to add an option to ProxyAndRecordSettings and use that to decide how to build the resulting mapping. Would that help?

Originally created by @steven-nelson-olo on GitHub (Sep 28, 2022). Originally assigned to: @StefH on GitHub. Hello. I use a third party SOAP service that I've been told I run tests against too often. I was hoping to use WireMock to proxy and record these requests. Then I'd like to use the recorded mappings as stubs going forward. To proxy and record the initial set, I use something like this: ``` c# server .Given(Request.Create().WithPath("/*") .WithBody(new RegexMatcher("<RequestType>Auth</RequestType"))) .WithTitle(rule.Name) .RespondWith(Response.Create().WithProxy(new ProxyAndRecordSettings { Url = proxyTarget, AllowAutoRedirect = true, SaveMapping = true, SaveMappingToFile = true, })); ``` Because it is a SOAP service, all the requests use the same URL. The request primarily differ on the body contents. Currently when I run these requests, it seems like a new mapping is creating, using the path and method to create a new title. Since the path and method are the same for each request, each request overwrites the one before it. It also seems that the regex matchers that were specified in the original mapping are being discarded in favor of matching the url, path, headers, and an exact match on the body of the request. If that understanding is correct, is there a way to work around this behavior to preserve the original mapping? If there isn't a work around, I'd like to submit a PR. In it, I'd try to add an option to ProxyAndRecordSettings and use that to decide how to build the resulting mapping. Would that help?
adam added the feature label 2025-12-29 15:24:11 +01:00
adam closed this issue 2025-12-29 15:24:11 +01:00
adam commented 2025-12-29 15:24:12 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Sep 28, 2022):

It also seems that the regex matchers that were specified in the original mapping are being discarded in favor of matching the url, path, headers, and an exact match on the body of the request.

I would expect that all matches would be used to find the correct/best match.

So what would be you proposal? Create a mapping-file-title also based on the body matcher?

@StefH commented on GitHub (Sep 28, 2022): > It also seems that the regex matchers that were specified in the original mapping are being discarded in favor of matching the url, path, headers, and an exact match on the body of the request. I would expect that all matches would be used to find the correct/best match. --- So what would be you proposal? Create a mapping-file-title also based on the body matcher?
adam commented 2025-12-29 15:24:13 +01:00
Author
Owner
Copy Link

@steven-nelson-olo commented on GitHub (Sep 28, 2022):

I'm surprised that the Path and Regex matcher aren't used for the saved mapping. I expect some immaterial changes in the request body, such as timestamps, so I wouldn't want an exact match on the request body saved in the mapping. But that seems to be what is happening.

For the title, I'd also expect it to be used for the mapping file as it was provided in the Given/RespondWith setup.

When I use version 1.3.10, the supplied title was used, but the response saved in the mapping was just the proxy url. In the current version, the Request and Response for the mapping look like they're recreated in the proxy helper instead of using what's stated in the Given/RespondWith methods.

@steven-nelson-olo commented on GitHub (Sep 28, 2022): I'm surprised that the Path and Regex matcher aren't used for the saved mapping. I expect some immaterial changes in the request body, such as timestamps, so I wouldn't want an exact match on the request body saved in the mapping. But that seems to be what is happening. For the title, I'd also expect it to be used for the mapping file as it was provided in the Given/RespondWith setup. When I use version 1.3.10, the supplied title was used, but the response saved in the mapping was just the proxy url. In the current version, the Request and Response for the mapping look like they're recreated in the proxy helper instead of using what's stated in the Given/RespondWith methods.
adam commented 2025-12-29 15:24:13 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Sep 28, 2022):

Just to clarify how it's currently implemented ->

None of the matchers defined in your request are used when the proxy mapping is saved (saved to memory or saved to file).

The ProxyHelper.cs gets all the things (path, method, body, headers, ...) and builds a new mapping.
And the title is set to $"Proxy Mapping for {requestMessage.Method} {requestMessage.Path}".

@StefH commented on GitHub (Sep 28, 2022): Just to clarify how it's currently implemented -> None of the matchers defined in your `request` are used when the proxy mapping is saved (saved to memory or saved to file). The `ProxyHelper.cs` gets all the things (path, method, body, headers, ...) and builds a new mapping. And the title is set to `$"Proxy Mapping for {requestMessage.Method} {requestMessage.Path}"`.
adam commented 2025-12-29 15:24:14 +01:00
Author
Owner
Copy Link

@steven-nelson-olo commented on GitHub (Sep 28, 2022):

That matches with what I've seen.

Because I'd like to reuse the mappings as stubs after they've been saved to a file, it would be nice if the matchers defined in the request are used when the proxy mapping is saved. Does that make sense, or does it run counter to an expected use case?

@steven-nelson-olo commented on GitHub (Sep 28, 2022): That matches with what I've seen. Because I'd like to reuse the mappings as stubs after they've been saved to a file, it would be nice if the matchers defined in the `request` are used when the proxy mapping is saved. Does that make sense, or does it run counter to an expected use case?
adam commented 2025-12-29 15:24:15 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Sep 29, 2022):

A possible solution could be to:

  • define a property UseDefinedRequestMatchers on the ProxyAndRecordSettings.cs
  • when this property is set, the ProxyHelper.cs should use these instead the default exact matchers.
  • so in your example the WithBody should use "<RequestType>Auth</RequestType" instead of an default exact matcher.
@StefH commented on GitHub (Sep 29, 2022): A possible solution could be to: - define a property `UseDefinedRequestMatchers` on the ProxyAndRecordSettings.cs - when this property is set, the ProxyHelper.cs should use these instead the default exact matchers. - so in your example the `WithBody` should use `"<RequestType>Auth</RequestType"` instead of an default exact matcher.
adam commented 2025-12-29 15:24:15 +01:00
Author
Owner
Copy Link

@steven-nelson-olo commented on GitHub (Sep 29, 2022):

That sounds like it would work to me. I've started working on a change that seems similar, but uses more of the mapping in the chance that more than the matchers might be wanted. I created a PR so you can see what I meant.

@steven-nelson-olo commented on GitHub (Sep 29, 2022): That sounds like it would work to me. I've started working on a change that seems similar, but uses more of the mapping in the chance that more than the matchers might be wanted. I created a PR so you can see what I meant.
adam commented 2025-12-29 15:24:16 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Sep 29, 2022):

See preview: 1.5.6-ci-16482

@StefH commented on GitHub (Sep 29, 2022): See preview: `1.5.6-ci-16482`
adam commented 2025-12-29 15:24:16 +01:00
Author
Owner
Copy Link

@steven-nelson-olo commented on GitHub (Sep 29, 2022):

I tested with 1.5.6-ci-16482

I was able to verify the recorded mappings are saved with the title from the request mapping, and that the request matchers are storing the matchers from the request. Looks good to me!

@steven-nelson-olo commented on GitHub (Sep 29, 2022): I tested with `1.5.6-ci-16482` I was able to verify the recorded mappings are saved with the title from the request mapping, and that the request matchers are storing the matchers from the `request`. Looks good to me!
adam commented 2025-12-29 15:24:16 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Sep 30, 2022):

https://github.com/WireMock-Net/WireMock.Net/pull/821

@StefH commented on GitHub (Sep 30, 2022): https://github.com/WireMock-Net/WireMock.Net/pull/821
adam commented 2025-12-29 15:24:16 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Sep 30, 2022):

A new official nuget version will be released in some days.

@StefH commented on GitHub (Sep 30, 2022): A new official nuget version will be released in some days.
adam commented 2025-12-29 15:24:17 +01:00
Author
Owner
Copy Link

@steven-nelson-olo commented on GitHub (Sep 30, 2022):

Thanks @StefH I appreciate all of your help!

@steven-nelson-olo commented on GitHub (Sep 30, 2022): Thanks @StefH I appreciate all of your help!
adam commented 2025-12-29 15:24:17 +01:00
Author
Owner
Copy Link

@steven-nelson-olo commented on GitHub (Oct 10, 2022):

Hello again @StefH
Is there any update on when we might see an official nuget version?

@steven-nelson-olo commented on GitHub (Oct 10, 2022): Hello again @StefH Is there any update on when we might see an official nuget version?
adam commented 2025-12-29 15:24:17 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Oct 11, 2022):

Later today.

@StefH commented on GitHub (Oct 11, 2022): Later today.
adam commented 2025-12-29 15:24:17 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Oct 11, 2022):

Done.

@StefH commented on GitHub (Oct 11, 2022): Done.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
bug
doc
doc
duplicate
feature
feature
invalid
pull-request
Mirrored from GitHub Pull Request
 question
wontfix
No Label feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/WireMock.Net-wiremock#455
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?