mirror of
https://github.com/wiremock/WireMock.Net.git
synced 2026-01-11 21:10:32 +01:00
FormEncoded Request fails (404 Not Found) if key value pairs order in mapping is different from request body order #615
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 @Xor-el on GitHub (Jul 24, 2024).
Originally assigned to: @StefH on GitHub.
Describe the bug
When trying to use the
ExactMatcherorRegexMatcherto match a form encoded request, it fails (404 Not Found) if they order of the form encoded request is different from that in the json mapping file.Expected behavior:
Ordering of FormEncoded Body requests should not affect matching as it might not always be convenient to control the ordering.
If it is going to be a breaking change to fix this, a flag like
IgnoreFormEncodedBodyOrdercan be provided to override the default.Test to reproduce
Other related info
Docker is needed to run the Demo as it uses WireMock.NET Test Container.
@StefH commented on GitHub (Jul 24, 2024):
The
ExactMatcherorRegexMatchershould just be used to match a string value. In case you want to match a form-urlencoded body, a better approach would be to add a new matcher likeFormUrlEncodedMatcherwhich can be used like this?@Xor-el commented on GitHub (Jul 24, 2024):
Hello @StefH thanks for your quick feedback.
I agree with your suggestion that adding a new matcher would be overall a better approach to address this.
Thanks for looking into this.
@StefH commented on GitHub (Jul 27, 2024):
https://github.com/WireMock-Net/WireMock.Net/pull/1147
@StefH commented on GitHub (Jul 27, 2024):
@Xor-el
Can you double check the PR (https://github.com/WireMock-Net/WireMock.Net/pull/1147)
And I've updated the wiki: https://github.com/WireMock-Net/WireMock.Net/wiki/Request-Matcher-FormUrlEncodedMatcher
@Xor-el commented on GitHub (Jul 27, 2024):
Hello @StefH Reviewing the PR and Doc now.
@Xor-el commented on GitHub (Jul 27, 2024):
So just reviewed this and everything looks awesome. Thanks.
while reviewing, a thought came to my head. does it make sense to have something like a
FormUrlEncodedPartialMatcher, similar to howJsonPartialMatcherdoes partial matching or does theMatchOperatorfunctionality cover this?@StefH commented on GitHub (Jul 27, 2024):
By default the
MatchOperatoris set to Or.So when the matcher is like:
And the body only contains
grant_type=client_credentials, this matcher will match.A
FormUrlEncodedPartialMatchercould be used like this (I think)...I'll check if I can change the implementation from the FormUrlEncodedMatcher to use internally the WildcardMatcher for string compare...
@Xor-el commented on GitHub (Jul 27, 2024):
and if it's the other way,
And the body contains
grant_type=client_credentials,client_id=DDCD99EE1531484E4E21D5EC9FBA5D8B, andclient_secret=RERDRDk5RUUxNTMxNDg0RTRFMjFENUVDOUZCQTVEOEI%3DI am guessing the matching would still work right or only theFormUrlEncodedPartialMatcherwould work then?@StefH commented on GitHub (Jul 27, 2024):
This does already work like it is because Or is used.
@Xor-el commented on GitHub (Jul 27, 2024):
great then, thanks.
@StefH commented on GitHub (Jul 27, 2024):
I've just updated the code so that wildcards are supported.
See the FormUrlEncodedMatcherTest for details.
@Xor-el commented on GitHub (Jul 27, 2024):
LGTM 🚀
@Xor-el commented on GitHub (Jul 29, 2024):
Hello @StefH I updated the test container package to version
1.5.62which I assume contains theFormUrlEncodedMatcherchanges.unfortunately, the matching still returns 404 error.
I updated the Demo to reflect this issue.
can you please confirm if I am missing something?
@StefH commented on GitHub (Jul 29, 2024):
I could not test using docker container, but I just started latest
dotnet-wiremockand updated your program.cs to be likeAnd it works:

In case you want to know why the mapping is not matched, follow this page:
https://github.com/WireMock-Net/WireMock.Net/wiki/Request-Matching-Tips
@Xor-el commented on GitHub (Jul 29, 2024):
@StefH my bad actually. I forgot to clear my Stale Docker Image Cache so my test container was using the old cached 1.5.60 instead of the latest 1.5.62 image.
Thanks for your time.
@StefH commented on GitHub (Jul 29, 2024):
@Xor-el
Currently the
latestis always used.Would it be needed to add an option to manually specify the version when using the containerbuilder? Or is this not needed?
@Xor-el commented on GitHub (Jul 29, 2024):
@StefH
So, Docker Desktop normally caches the downloaded image and reuses it on subsequent builds if it exists so I don't think there is much you can do about that on your end except there is a way to force Docker to always pull when a build is about to happen (but this has it's own disadvantage too).
it would be nice to have the ability to pin the version we wish to use to enable users to work around scenarios like this, which happened some days back to the SQL Server test container image.
@StefH commented on GitHub (Jul 29, 2024):
Can you create a new issue please?
@Xor-el commented on GitHub (Jul 29, 2024):
sure, on it.