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

Request matching logic is not practical #70

New Issue
Closed
opened 2025-12-29 14:21:59 +01:00 by adam · 7 comments
adam commented 2025-12-29 14:21:59 +01:00
Owner
Copy Link

Originally created by @davidshen84 on GitHub (Feb 28, 2018).

I did not read the code. I did some testing, and I think current request matching logic is:

  • AllowPartialMapping = false, all the properties in the received request must be tested positive by the matching rules, which means unspecified properties will be automatically tested negative. This is rather restrictive and is hard to satisfy.

  • AllowPartialMapping = true, *at least one of the matching rules must satisfy at least one of the properties in the received request. This is rather lose and useless.

I suggest we change the matching logic to the following:

  • AllowPartialMapping = false, remain the same.
  • AllowPartialMapping = true, all the matching rules must test positive against the received request, and properties in the request that are not tested are ignored.

With the new logic, when partial matching is enabled, the engine will test the properties of requests that matters to the application, and ignore the other ones.

Originally created by @davidshen84 on GitHub (Feb 28, 2018). I did not read the code. I did some testing, and I think current request matching logic is: - AllowPartialMapping = false, **all the properties** in the received request must be tested positive by the matching rules, which means **unspecified properties will be automatically tested negative**. *This is rather restrictive and is hard to satisfy.* - AllowPartialMapping = true, **at least one* of the matching rules must satisfy **at least one** of the properties in the received request. *This is rather lose and useless.* I suggest we change the matching logic to the following: - AllowPartialMapping = false, *remain the same.* - AllowPartialMapping = true, **all the matching rules** must test positive against the received request, and properties in the request that are not tested are ignored. With the new logic, when partial matching is enabled, the engine will test the properties of requests that matters to the application, and ignore the other ones.
adam added the question label 2025-12-29 14:21:59 +01:00
adam closed this issue 2025-12-29 14:21:59 +01:00
adam commented 2025-12-29 14:22:00 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Feb 28, 2018):

  • AllowPartialMapping = false ; your description is correct
  • AllowPartialMapping = true ; the best matching request is matched (the request with the highest score)

When you do a GET call to __admin/requests you get details about the matching:

"RequestMatchResult": {
	"TotalScore": 2.666666666666667,
	"TotalNumber": 3,
	"IsPerfectMatch": false,
	"AverageTotalScore": 0.888888888888889,
	"MatchDetails": [
		{
			"Name": "PathMatcher",
			"Score": 1
		},
		{
			"Name": "MethodMatcher",
			"Score": 1
		},
		{
			"Name": "BodyMatcher",
			"Score": 0.66666666666666674
		}
	]
}
@StefH commented on GitHub (Feb 28, 2018): - `AllowPartialMapping = false` ; your description is correct - `AllowPartialMapping = true` ; the **best** matching request is matched (the request with the highest score) When you do a GET call to `__admin/requests` you get details about the matching: ``` "RequestMatchResult": { "TotalScore": 2.666666666666667, "TotalNumber": 3, "IsPerfectMatch": false, "AverageTotalScore": 0.888888888888889, "MatchDetails": [ { "Name": "PathMatcher", "Score": 1 }, { "Name": "MethodMatcher", "Score": 1 }, { "Name": "BodyMatcher", "Score": 0.66666666666666674 } ] } ```
adam commented 2025-12-29 14:22:00 +01:00
Author
Owner
Copy Link

@davidshen84 commented on GitHub (Feb 28, 2018):

Suppose I have a simple service endpoint that

  • path /getdata
  • accept GET only
  • requires header AppId: app-1234

If I create a mock server with the following code:

var _server = Fluent();
_server.AllowPartialMapping = true;
_server
  .Given(Request.Create()
    .UsingGet())
  .RespondWith(Response.Create()
    .WithStatusCode(HttpStatusCode.OK));

This configuration all accept any GET request. If the client code missed some HTTP request property, this will still allow the client getting the expected response. This can hide some potential bugs that can only be found at production environment.

@davidshen84 commented on GitHub (Feb 28, 2018): Suppose I have a simple service endpoint that - path `/getdata` - accept `GET` only - requires header `AppId: app-1234` If I create a mock server with the following code: ``` var _server = Fluent(); _server.AllowPartialMapping = true; _server .Given(Request.Create() .UsingGet()) .RespondWith(Response.Create() .WithStatusCode(HttpStatusCode.OK)); ``` This configuration all accept any GET request. If the client code missed some HTTP request property, this will still allow the client getting the expected response. This can hide some potential bugs that can only be found at production environment.
adam commented 2025-12-29 14:22:00 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Feb 28, 2018):

This could indeed be a problem for production environment, I can add some more details on the WIKI to explain how AllowPartialMapping = true works ?

@StefH commented on GitHub (Feb 28, 2018): This could indeed be a problem for production environment, I can add some more details on the WIKI to explain how `AllowPartialMapping = true` works ?
adam commented 2025-12-29 14:22:00 +01:00
Author
Owner
Copy Link

@davidshen84 commented on GitHub (Mar 3, 2018):

By my past experience with other rule matching framework, if the user specified a matching rule, only the matching result of the rule affect the final result. Users normally do not concern about the conditions they did not specify. That's just my opinion.

@davidshen84 commented on GitHub (Mar 3, 2018): By my past experience with other rule matching framework, if the user specified a matching rule, only the matching result of the rule affect the final result. Users normally do not concern about the conditions they did not specify. That's just my opinion.
adam commented 2025-12-29 14:22:00 +01:00
Author
Owner
Copy Link

@alastairtree commented on GitHub (Mar 3, 2018):

In my experience having the mock server be quite forgiving is good as it allows you to have general rules that return a 200 say, and then a particular payload on a certain path. This makes generating the mock fast. However in the assertion parts of my tests I call the admin API to get the request I have made and then assert that my desired behaviours, such as sending headers, have be actioned appropriately.

@alastairtree commented on GitHub (Mar 3, 2018): In my experience having the mock server be quite forgiving is good as it allows you to have general rules that return a 200 say, and then a particular payload on a certain path. This makes generating the mock fast. However in the assertion parts of my tests I call the admin API to get the request I have made and then assert that my desired behaviours, such as sending headers, have be actioned appropriately.
adam commented 2025-12-29 14:22:00 +01:00
Author
Owner
Copy Link

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

The recent release also includes MatchBehaviour.RejectOnMatch which also make crafting complex matching rules easier to exclude certain requests from matching.

@alastairtree commented on GitHub (May 17, 2018): The recent release also includes MatchBehaviour.RejectOnMatch which also make crafting complex matching rules easier to exclude certain requests from matching.
adam commented 2025-12-29 14:22:01 +01:00
Author
Owner
Copy Link

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

@davidshen84 Do you gave more questions? Else I'll close this issue.

@StefH commented on GitHub (May 19, 2018): @davidshen84 Do you gave more questions? Else I'll close this issue.
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 question
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#70
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?