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

New Issue

Closed

opened 2025-12-29 08:28:26 +01:00 by adam · 14 comments

adam commented 2025-12-29 08:28:26 +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 08:28:26 +01:00

adam closed this issue 2025-12-29 08:28:26 +01:00

adam commented 2025-12-29 08:28:27 +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 08:28:27 +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 08:28:28 +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 08:28:28 +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 08:28:28 +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 08:28:28 +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 08:28:29 +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 08:28:29 +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 08:28:29 +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 08:28:29 +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 08:28:29 +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 08:28:29 +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 08:28:29 +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 08:28:30 +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

master

mime-part-matcher

version-2.x

MappingSerializer

1341-mapping-json

stef-aspire-tests-updates

bug/973-TinyMapper

bug/1149-AppendGuidToSavedMappingFile

feature/1150-DockerImageVersion

61

stef-1108

stef-1097

stef-1083-MessageOptions_Type_Conflict

stef-1062-logger

stef-IgnoreOpenApiErrors

stef-928-TypeLoadException-FluentAssertions-net472

nunit

stef-849

stef-847-regex-questionmark

http_verb

WireMockServerContext

webapp

ai

CommandLineArgumentsParser

1.23.0

1.22.0

1.21.0

1.20.0

1.19.0

1.18.0

1.17.0

1.16.0

1.15.0

1.14.0

1.13.0

1.12.0

1.11.2

1.11.0

1.10.1

1.10.0

1.9.1

1.9.0

1.8.18

1.8.17

1.8.16

1.8.15

1.8.14

1.8.13

1.8.12

1.8.11

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.3

1.8.2

1.8.1

1.8.0

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.12

1.6.11

1.6.10

1.6.9

1.6.8

1.6.7

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.62

1.5.61

1.5.60

1.5.59

1.5.58

1.5.57

1.5.56

1.5.55

1.5.54

1.5.53

1.5.52

1.5.51

1.5.50

1.5.49

1.5.48

1.5.47

1.5.46

1.5.45

1.5.44

1.5.43

1.5.42

1.5.41

1.5.40

1.5.39

1.5.38

1.5.37

1.5.36

1.5.35

1.5.34

1.5.33

1.5.32

1.5.31

1.5.30

1.5.29

1.5.28

1.5.27

1.5.26

1.5.25

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.43

1.4.42

1.4.41

1.4.40

1.4.39

1.4.38

1.4.37

1.4.36

1.4.35

1.4.34

1.4.33

1.4.32

1.4.31

1.4.30

1.4.29

1.4.28

1.4.27

1.4.26

1.4.25

1.4.24

1.4.23

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.10

1.3.9

1.3.8

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11.0

1.2.10

1.2.9.0

1.2.8.0

1.2.7.0

1.2.6.0

1.2.5.0

1.2.4.0

1.2.3.0

1.2.2.0

1.2.1.0

1.2.0.0

1.1.10

1.1.9.0

1.1.8.0

1.1.7.0

1.1.6.0

1.1.5.0

1.1.3.0

1.1.2.0

1.1.1.0

1.1.0.0

1.0.43.0

1.0.42.0

1.0.41.0

1.0.40.0

1.0.39.0

1.0.38.0

1.0.37.0

1.0.36.0

1.0.35.0

1.0.34.0

1.0.33.0

1.0.32.0

1.0.31.0

1.0.29.0

1.0.28.0

1.0.25.0

1.0.24.0

1.0.23.0

1.0.22.0

1.0.21.0

1.0.20.0

1.0.19.0

1.0.18.0

1.0.17.0

1.0.16.0

1.0.15.0

1.0.14.0

1.0.13.0

1.0.12.0

1.0.11.0

1.0.10.0

1.0.9.0

1.0.8.0

1.0.7.0

1.0.6.1

1.0.6

1.0.5

1.0.4.21

1.0.4.20

1.0.4.19

1.0.4.18

1.0.4.17

1.0.4.16

1.0.4.15

1.0.4.14

1.0.4.13

1.0.4.12

1.0.4.11

1.0.4.10

1.0.4.9

1.0.4.8

1.0.4.7

1.0.4.6

1.0.4.5

1.0.4.4

1.0.4.3

1.0.4.2

1.0.4.1

1.0.4.0

1.0.3.20

1.0.3.19

1.0.3.18

1.0.3.17

1.0.3.16

1.0.3.15

1.0.3.14

1.0.3.13

1.0.3.12

1.0.3.11

1.0.3.10

1.0.3.9

1.0.3.8

1.0.3.7

1.0.3.6

1.0.3.5

1.0.3.4

1.0.3.3

1.0.3.2

1.0.3.1

1.0.3.0

1.0.2.13

1.0.2.12

1.0.2.11

1.0.2.10

1.0.2.9

1.0.2.8

1.0.2.7

1.0.2.6

1.0.2.5

1.0.2.4

1.0.2.1

1.0.2.0

1.0.1.5

1.0.1.3

1.0.1.2

1.0.1.1

1.0.0.0

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

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/WireMock.Net#455