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

New Issue

adam · 2025-12-29T14:22:28+01:00

adam commented

2025-12-29 14:22:28 +01:00

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 question bug 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

@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

@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

@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

@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

@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

@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.

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 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/WireMock.Net-wiremock#98