[
https://issues.apache.org/jira/browse/CXF-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16156049#comment-16156049
]
ASF GitHub Bot commented on CXF-7491:
-------------------------------------
Github user cchepelov commented on the issue:
https://github.com/apache/cxf/pull/309
Thanks for the feedback @sberyozkin
As noted in the JIRA ticket, I hesitated between simply updating the
existing interceptors and forking/deprecating. The reason why I went with the
latter is in order to avoid making a breaking interface change for users of
_subclasses_ of these interceptors, which seemed to be an excessive surprise in
a possible 3.1.(x+1) release. In the patch as it is now, the **features** are
updated to use the new interceptors.
Do you feel I overestimated the inconvenience to such subclassers, at the
expense of leaving (effectively) dead/worse code around ? I'll gladly switch to
the break-but-improve-in-place strategy if this is preferred.
> TransformInInterceptor / TransformOutInterceptor assume UTF-8, ignore
> header-provided character set
> ---------------------------------------------------------------------------------------------------
>
> Key: CXF-7491
> URL: https://issues.apache.org/jira/browse/CXF-7491
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 3.1.11, 3.1.12
> Environment: client Linux/Java/CXF (actually scala using
> sbt-play-soap)
> server IBMi AS/400
> Reporter: Cyrille Chépélov
>
> When talking to a server using IBMi / RPG-based software and SOAP gateway:
> the returned SOAP message contains XML encoded as ISO-8859-1; the HTTP header
> do specify a content type of xml+soap with character set ISO-8859-1; however
> the XML message itself include no character set declaration.
> Due to discrepancies between the official WSDL for the SOAP message and the
> remote implementation, a couple transforms had to be deployed. This works
> fine as long as the exchanged messages actually conform to US-ASCII (no
> diacritics), but whenever any character encoded differently between
> ISO-8859-1 and UTF-8 is used, the TransformInInterceptor fails to parse the
> text, as the XMLStreamReader is built to expect UTF-8 and actually receives
> ISO-8859-1 input
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
