[
https://issues.apache.org/jira/browse/CXF-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766170#action_12766170
]
Daniel Kulp commented on CXF-2475:
----------------------------------
Let me try and rephrase the issue:
When producing a response, in the absence of a user override (more on this in a
second), CXF (or any service) needs to choose some charset in which to generate
the response. There are several options that can be chosen:
1) Use the Accept-Charset header - this would be ideal except that nobody uses
it. I don't think any of the soap toolkit actually send it. That said, if
it's there it would probably be good to use. Not using it is probably
considered a bug. If it's not there, we need to fall down to other options.
2) Always use UTF-8 - definitely a viable option now and might make sense to
do. The PROBLEM with this that we encountered early in the soap days (think
2000-2003 timeframes and such) is that not all embedded devices and such
understood UTF-8. Think about things like the embedded stuff in the LeapFrog
Leapster toys and such that aren't running java. You could probably argue
that they should then send an Accept-Charset, but they don't.
3) Use the incoming request charset - we went this option because if they sent
it in that charset, we know they understand it (in theory, otherwise, how would
they be able to send it).
Anyway, in the early days of soap interopability testing, option 3 was pretty
much determined to be the best option to make sure clients could understand the
responses. That said, all the modern things all talk utf-8 pretty well, thus
we could possibly change it to default to utf-8.
Now, the question this issue really raises is "if I don't want the above
behavior, how do I override it?" which is definitely a valid question. You are
trying to override it by calling setCharacterEncoding(...) on the
HttpServletResponse object prior to CXF doing anything with it. To me, that
is not really an approriate way for a couple reasons:
1) There isn't a way to determine if you called setCharacterEncoding or not.
If getCharacterEncoding would return null if set wasn't called, that would be
one thing. However, getCharacterEncoding() returns ISO-8859-1(per servlet
spec) if set isn't called. Thus, we have no idea if you had called
setCharacterEncoding("ISO-8859-1") and really want that or not.
2) Requires a subclass of the CXF servlet or similar to set it. Not
something we normally would encourage. It also doesn't work for the embedded
Jetty case. Also doesn't work for the other transports like JMS and the Local
transport.
#2 is kind of key. Whatever mechanism is chosen, it needs to work for all
the various transports. Also, it needs to be able to be set on a
per-invokation basis based on knowledge of what is being generated/returned.
I THINK (haven't actually tried this) that it can easily be achieved today via
the WebServiceContext. ctx.getMessageContext().put(Message.ENCODING,
"UTF-8"); in the service method probably will do it. An interceptor on the
out chain could also do it. We could also provide a contextual property
(configurable per-endpoint or bus in the spring config) to specify a default as
well if we thought that made sense.
> When writing XML response, CXF uses request encoding instead of response
> encoding
> ---------------------------------------------------------------------------------
>
> Key: CXF-2475
> URL: https://issues.apache.org/jira/browse/CXF-2475
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.2.4, 2.2.5
> Reporter: Michael Allman
> Priority: Minor
> Attachments: AbstractHTTPDestination.patch
>
>
> When writing the SOAP XML response, CXF uses the ServletRequest encoding
> instead of the ServletResponse encoding.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
