starred/WireMock.Net-wiremock
1
0
Fork 0
mirror of https://github.com/wiremock/WireMock.Net.git synced 2026-07-31 17:28:49 +02:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

Issue: Wildcard matching a json body does not work? #98

New Issue
Closed
opened 2025-12-29 14:22:28 +01:00 by adam · 6 comments
adam commented 2025-12-29 14:22:28 +01:00
Owner
Copy Link
Copy Source

Originally created by @alastairtree on GitHub (May 11, 2018).

Originally assigned to: @StefH on GitHub.

Hello @StefH,

I have noticed that if I try to match request bodies containing json, I am restricted to using the JsonPathMatcher. Sometimes it is quicker and easier to use wildcard or regex matchers (say) but these matchers just get ignored if the content type header is set as application/json. This is not exactly intuitive - that a request header affects which of the matchers are applied or silently ignored. I assume this was a deliberate decision? Is there a reason you do not want to support the other matcher types on json? (and I assume the same is in place with xml.)

Sample failing test:

    [Fact]
    public async Task FluentMockServer_Should_respond_to_wildcard_matching_even_when_sent_as_json()
    {
        // Assign
        _server = FluentMockServer.Start();

        _server
            .Given(Request.Create().WithPath("/foo").WithBody(new WildcardMatcher("*Hello server*")))
            .RespondWith(Response.Create().WithBody(@"{ ""message"" : ""Hello client"" }"));

        // Act
        var content = new StringContent(@"{ ""message"" : ""Hello server"" }", Encoding.UTF8, "application/json");
        var response = await new HttpClient().PostAsync("http://localhost:" + _server.Ports[0] + "/foo", content);

        // Assert
        var responseString = await response.Content.ReadAsStringAsync();
        Check.That(responseString).Contains("Hello client");
    }
Originally created by @alastairtree on GitHub (May 11, 2018). Originally assigned to: @StefH on GitHub. Hello @StefH, I have noticed that if I try to match request bodies containing json, I am restricted to using the JsonPathMatcher. Sometimes it is quicker and easier to use wildcard or regex matchers (say) but these matchers just get ignored if the content type header is set as application/json. This is not exactly intuitive - that a request header affects which of the matchers are applied or silently ignored. I assume this was a deliberate decision? Is there a reason you do not want to support the other matcher types on json? (and I assume the same is in place with xml.) Sample failing test: [Fact] public async Task FluentMockServer_Should_respond_to_wildcard_matching_even_when_sent_as_json() { // Assign _server = FluentMockServer.Start(); _server .Given(Request.Create().WithPath("/foo").WithBody(new WildcardMatcher("*Hello server*"))) .RespondWith(Response.Create().WithBody(@"{ ""message"" : ""Hello client"" }")); // Act var content = new StringContent(@"{ ""message"" : ""Hello server"" }", Encoding.UTF8, "application/json"); var response = await new HttpClient().PostAsync("http://localhost:" + _server.Ports[0] + "/foo", content); // Assert var responseString = await response.Content.ReadAsStringAsync(); Check.That(responseString).Contains("Hello client"); }
adam added the questionbug labels 2025-12-29 14:22:28 +01:00
adam closed this issue 2025-12-29 14:22:29 +01:00
adam commented 2025-12-29 14:22:30 +01:00
Author
Owner
Copy Link
Copy Source

@StefH commented on GitHub (May 11, 2018):

It was not a 100% deliberate decision, this seemed logical at the time I built this piece of code.

I'll see if I can extend the matching logic to support this scenario, and not break others ;-)

@StefH commented on GitHub (May 11, 2018): It was not a 100% deliberate decision, this seemed logical at the time I built this piece of code. I'll see if I can extend the matching logic to support this scenario, and not break others ;-)
adam commented 2025-12-29 14:22:30 +01:00
Author
Owner
Copy Link
Copy Source

@StefH commented on GitHub (May 11, 2018):

@alastairtree
Please do a code-review on my stef_133 branch.

See specifically the changes in RequestMessageBodyMatcher.cs.

@StefH commented on GitHub (May 11, 2018): @alastairtree Please do a code-review on my `stef_133` branch. See specifically the changes in `RequestMessageBodyMatcher.cs`.
adam commented 2025-12-29 14:22:30 +01:00
Author
Owner
Copy Link
Copy Source

@alastairtree commented on GitHub (May 12, 2018):

@StefH I have reviewed and added a couple more tests. I was wondering if it would be tidier to put the string version of the json in the BodyAsString property rather than adding a third? Other than that it looks good to me.

@alastairtree commented on GitHub (May 12, 2018): @StefH I have reviewed and added a couple more tests. I was wondering if it would be tidier to put the string version of the json in the BodyAsString property rather than adding a third? Other than that it looks good to me.
adam commented 2025-12-29 14:22:30 +01:00
Author
Owner
Copy Link
Copy Source

@StefH commented on GitHub (May 12, 2018):

Thanks for tour tests, and [Theory] is cool option which I should more in my unit-tests in general.

If I remove the BodyAsStringOriginal property, I think I need to switch the code into this:

// Check if the matcher is a IStringMatcher
if (Matcher is IStringMatcher stringMatcher)
{
	// If the  body is a JSON object, try to use the Body to match.
	if (requestMessage.BodyAsJson != null && requestMessage.Body != null)
	{
		return stringMatcher.IsMatch(requestMessage.Body);
	}
	
	// If the string body is defined, try to match.
	if (requestMessage.Body != null)
	{
		return stringMatcher.IsMatch(requestMessage.Body);
	}
}

Else the logic will not work? Correct ?

@StefH commented on GitHub (May 12, 2018): Thanks for tour tests, and `[Theory]` is cool option which I should more in my unit-tests in general. If I remove the `BodyAsStringOriginal` property, I think I need to switch the code into this: ``` c# // Check if the matcher is a IStringMatcher if (Matcher is IStringMatcher stringMatcher) { // If the body is a JSON object, try to use the Body to match. if (requestMessage.BodyAsJson != null && requestMessage.Body != null) { return stringMatcher.IsMatch(requestMessage.Body); } // If the string body is defined, try to match. if (requestMessage.Body != null) { return stringMatcher.IsMatch(requestMessage.Body); } } ``` Else the logic will not work? Correct ?
adam commented 2025-12-29 14:22:31 +01:00
Author
Owner
Copy Link
Copy Source

@alastairtree commented on GitHub (May 13, 2018):

Yeah that looks good to me, and those tests should make sure the basics are not broken. How should it behave of there are more than one body matcher? Do we have tests covering that?

@alastairtree commented on GitHub (May 13, 2018): Yeah that looks good to me, and those tests should make sure the basics are not broken. How should it behave of there are more than one body matcher? Do we have tests covering that?
adam commented 2025-12-29 14:22:31 +01:00
Author
Owner
Copy Link
Copy Source

@StefH commented on GitHub (May 13, 2018):

The RequestMessageBodyMatcher do only allow for 1 matcher, as opposed to e.g. RequestMessageHeaderMatcher which does allow multiple.

I'll make a PR and add you as reviewer. And when all is fine, I can merge and create a new version.

@StefH commented on GitHub (May 13, 2018): The `RequestMessageBodyMatcher` do only allow for 1 matcher, as opposed to e.g. `RequestMessageHeaderMatcher` which does allow multiple. I'll make a PR and add you as reviewer. And when all is fine, I can merge and create a new version.
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 labels bug question
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/WireMock.Net-wiremock#98