-
Notifications
You must be signed in to change notification settings - Fork 38.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce setDefaultCharacterEncoding()
in MockHttpServletResponse
#27214
Comments
Are you aware of the |
@sbrannen Yes I saw the method, but I didn't think of a way to do it by default. I guess I could write a custom The rest of the ticket is still valid with the somewhat unexpected behaviour. |
You could write a custom Note, however, that setting the character encoding via In light of that, I am going to repurpose this issue to introduce support for changing the default character encoding used in
Although I can see how you might have expected @rstoyanchev, do you have any further input here? |
setDefaultCharacterEncoding()
in MockHttpServletResponse
This has been addressed via a new @jhyot, feel free to try this out in an upcoming 5.3.10 snapshot. |
Thank you for adding this. |
See #27230 for support for this new feature in |
Prior to this commit, it was possible to set the character encoding in MockHttpServletResponse via setCharacterEncoding() or setContentType(); however, those methods append "charset=..." to the Content-Type header which may not be an acceptable side effect. This commit addresses this shortcoming by introducing a new setDefaultCharacterEncoding() in MockHttpServletResponse which allows one to override the previously hard coded value of "ISO-8859-1". In addition, setDefaultCharacterEncoding() does not modify the Content-Type header. The reset() method has also been updated to reset the character encoding to the configured default character encoding. Closes spring-projectsgh-27214
@sbrannen sorry for excavating an old issue. I can log new one if it has a chance to live. Is there a chance the test framework can follow RFC 4627 out of the box? If it did - It would make tests behavior more representable of real-world behavior. Workaround is not complex, but it felt as a "least surprise principle" violation, and I saw way too many imprecise workarounds:
I ended up adding such code, but it felt quite wordy:
|
Since: Spring 5.2 and the deprecation of
APPLICATION_JSON_UTF8
Mediatype.Although the content type 'application/json' can only be encoded in UTF-8 (which is why the explicit encoding was deprecated),
MockHttpServletResponse#getCharacterEncoding()
returns 'ISO-8859-1'.This breaks any test code that inspects or uses the
getCharacterEncoding()
directly. But more unexpectedly, it breaksMockHttpServletResponse#getContentAsString()
, because the response is decoded with ISO-8859-1 instead of UTF-8. Explicitly usingMockHttpServletResponse#getContentAsString(Charset fallbackCharset)
works correctly.The Javadoc for
getContentAsString()
is (to me) somewhat ambiguous:"using the charset specified for the response by the application" could imply UTF-8 for 'application/json', because that must always be the value for JSON. If using this interpretation, then the method breaks its Javadoc contract.
Previously, this was fixed for
ContentResultMatchers#json(String)
but not forMockHttpServletResponse#getContentAsString()
(#23622).Another report was closed by the submitter without any resolution except using an explicit charset (#23851).
If it is not possible to fix this for JSON specifically, I would appreciate if somehow a default value could be set (instead of always defaulting to ISO-8859-1).
The text was updated successfully, but these errors were encountered: