559: fix multiple encodings of params #738
Conversation
|
@Climax85 Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
|
@Climax85 Thank you for signing the Contributor License Agreement! |
There was a problem hiding this comment.
I am not sure about this one. The test cases don't seem to check for any double encoding in the first place. Their names aren't quite telling what the intend of the tests are actually.
Also, see my comment on checkParams(…). I didn't actually get the intention of the method.
|
I second @olivergierke 's comments. I'd start with a battery of tests exposing the issue at hand. In fact, the code you from #559 would be a perfect candidate to put into a unit test that you could then test away at ensuring it acts properly. |
|
Any update here? This bug makes ControllerLinkBuilder pretty much useless for non-template URLs. |
|
Do you have a test case that exposes the problems here? Also, there have been considerable changes to Spring HATEOAS since this ticket was opened including:
Please tell me if the latest version (1.1.0.M3 just came out) solves your problems. If not, can you provide a test case illustrating the issue. |
odrotbohm
force-pushed
the
main
branch
3 times, most recently
from
2e02d7a
to
856b6b9
Compare
odrotbohm
force-pushed
the
main
branch
4 times, most recently
from
5828e78
to
e643c37
Compare
In order to #559 I got multiple encodings using the ControllerLinkBuilder. I added corresponding tests and fixed the issue. The ControllerLinkBuilder#bindRequestParameters method already encodes the params in the template url. Any further expand of the url will encode the % sign in %25. So no additional encoding should be done.
The Link#expand method is not only used to expand parameters in the template but also to check for missing required parameters.
I added another checkParams method to the UriTemplate class to only check the params but not encoding them.