encode soap request body with the configured charset#3433
Merged
Conversation
velo
approved these changes
Jun 23, 2026
velo
left a comment
Member
There was a problem hiding this comment.
This is the right fix for the SOAP charset path: keep the marshalled bytes and pass the configured charset through to RequestTemplate. The UTF-16 non-ASCII tests in both SOAP modules cover the regression well.
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Repro: configure
SOAPEncoderwithwithCharsetEncoding(UTF-16)and encode an object whose body holds a non-ASCII character (e.g.Café).Expected: the request body bytes match the
UTF-16declared in the XML prolog the marshaller wrote.Actual: the body is mangled.
SOAPEncoder.encodewrites the message to aByteArrayOutputStreamincharsetEncoding, then the soap module doesnew String(bos.toByteArray())and soap-jakarta doesbos.toString(). Both decode those bytes with the JVM platform default charset, andRequestTemplate.body(String)re-encodes asUTF-8, so the configured encoding is dropped and any non-ASCII content is corrupted (pure ASCII survives by accident, which is why the existing tests miss it).Fix: hand the marshalled bytes to
template.body(bos.toByteArray(), charsetEncoding)in both modules, the same wayUrlencodedFormContentProcessoralready passes bytes plus charset.Regression test in both
SOAPCodecTestfiles encodes non-ASCII content underUTF-16.