Encoding in AbstractHttpRequestExecutingMessageHandler.java is now done when flag is set#2929
Conversation
…ne when flag is set
|
@ezylot Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
|
@ezylot Thank you for signing the Contributor License Agreement! |
artembilan
left a comment
There was a problem hiding this comment.
Please, add your name to the @author list and modify, please, HttpRequestExecutingMessageHandlerTests.testUriExpression() to reflect your change.
This way we definitely going to have a test coverage.
Thank you!
|
I added myself as an author and added 2 tests that check this specific problem |
artembilan
left a comment
There was a problem hiding this comment.
Please, fix Checkstyle violation
| import java.util.LinkedHashMap; | ||
| import java.util.List; | ||
| import java.util.Map; | ||
| import java.util.*; |
There was a problem hiding this comment.
No asterisk imports at all, please.
There was a problem hiding this comment.
Oh boy, did not check that. Fixed.
artembilan
left a comment
There was a problem hiding this comment.
LGTM
Will merge after green Travis report.
|
There are still a couple Checkstyle violations: |
|
Damnit, give me a second ^^ |
|
should be good to go, i think ;) |
|
Sorry, have missed your fresh commit somehow... Now it is merged and I'm going to cherry-pick it to Thank you for contribution; looking forward for more! |
Before we did not actually encode the URI. You can see this in the screenshot below, where the String "häuser" is not actually encoded to the correct percentage encoding.
When we first encode it and then call the .toUri() we can see that the "häuser" is now propoerly encoded to "h%C3%A4user"