mirror of
https://github.com/wiremock/WireMock.Net.git
synced 2026-01-11 21:10:32 +01:00
Unexpected behavior on multiple params matching #280
Reference in New Issue
Block a user
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?
Originally created by @devzaak on GitHub (Jul 13, 2020).
What is the expected purpose of
I expected that this setup would match on any of the provided values, but it rejects all of the requests with any of those values?
I know I can get this to match by providing linq or c# matcher as alternative, but just wanted to clarify purpose of the params?
Cheers
@StefH commented on GitHub (Jul 13, 2020):
Hello @aslezak,
The current intended behaviour from this logic is that you define that the
limitparameter should be defined 3 times and have the values0,1and2. So it's basically an AND.See this unit test which should explain it:
d971144426/test/WireMock.Net.Tests/RequestTests.cs (L126)If you want to match on
0or1or2, the best solution is to use a RegexMatcher.So
@StefH commented on GitHub (Jul 13, 2020):
A structural change could be to add another parameter which defines if the match result should be calculated using an AND or an OR. I'll think about this....
@devzaak commented on GitHub (Jul 13, 2020):
Thanks for the unit test and regex idea.
One thing I am curious about is in what cases does one want in url to have query param multiple times with different values. I know that some languages process multiple query string keys differently. PHP takes only the first one unless it is array, c# does array and so on.
ps. if match operator option is something that can be done, happy to make a PR for it.
Cheers
@StefH commented on GitHub (Jul 13, 2020):
Multiple times the same param or single param with multiple values is the same.
So
?limit=1,2
Is same as
?limit=1&limit=2
You can try to make PR however this involves a lot if API changes and internal changes.
@devzaak commented on GitHub (Jul 13, 2020):
Thanks for the head up, haven't looked much into internals yet.
I think for now you can definitely close this issue, got the answers I was after, and will see when I have time how much changes the operator would involve.
Thanks for the quick reply!
@StefH commented on GitHub (Jul 14, 2020):
I'll keep this open for now and see if I can add this somewhere in the documentation.
And I'll check the changes needed.