[
https://issues.apache.org/jira/browse/AXIS2-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720663#action_12720663
]
Christian Gosch commented on AXIS2-4386:
----------------------------------------
Fortunately the web service in question is currently the only one my
application has to talk to -- but as far as I can see this "general" content
type will cause all "usual" web services called via this configuration being
processed by my custom message builder -- right?
Or is the content type "text/xml" already somewhat specific (and not simply the
"usual default type")?
(This question may also be useful for other readers of this thread having to
deal with different web services to be called from one application.)
> Add some tolerance to BuilderUtil.validateCharSetEncoding()
> -----------------------------------------------------------
>
> Key: AXIS2-4386
> URL: https://issues.apache.org/jira/browse/AXIS2-4386
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: client-api
> Affects Versions: 1.4.1
> Environment: IBM WebSphere Application Server 6.0.2.29 / IBM JRE
> 1.4.2 SR11
> Reporter: Christian Gosch
>
> I currently try to use a given web service which returns "inconsistent"
> responses concerning the encoding setup: The HTTP header is set and claims to
> head an ISO-8859-1 response, but the XML content itself claims to be of
> UTF-8. As far as I can see this causes my Axis2 1.4.1 client (generated based
> on xmlbeans 2.3) to throw the following exception:
> org.apache.axis2.AxisFault: Character Set Encoding from transport information
> [ISO-8859-1] does not match with character set encoding in the received SOAP
> message [UTF-8]
> at
> org.apache.axis2.builder.BuilderUtil.validateCharSetEncoding(BuilderUtil.java:786)
> at
> org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:57)
> at
> org.apache.axis2.transport.TransportUtils.createDocumentElement(TransportUtils.java:164)
> at
> org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:112)
> at
> org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:88)
> at
> org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:353)
> at
> org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:416)
> at
> org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
> at
> org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
> [...]
> The response itself looks like:
> "HTTP/1.1 200 OK[\r][\n]"
> "HTTP/1.1 200 OK[\r][\n]"
> "Date: Tue, 16 Jun 2009 15:02:40 GMT[\r][\n]"
> "Server: Apache-Coyote/1.1[\r][\n]"
> "X-Powered-By: Servlet 2.4; Tomcat-5.0.28/JBoss-3.2.6 (build:
> CVSTag=JBoss_3_2_6 date=200410140106)[\r][\n]"
> "Content-Type: text/xml;charset=ISO-8859-1[\r][\n]"
> "Content-Length: 475[\r][\n]"
> "[\r][\n]"
> "<?xm"
> "l version="1.0" encoding="UTF-8"?>[\n]"
> "<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";><Body><soapenv:Fault
> xmlns=""><faultcode>soapenv:Client</faultcode><faultstring>Error in
> parsing</faultstring><detail><detaildata>Content is not allowed in
> prolog.</detaildata></detail></soapenv:Fault></Body></Envelope>"
> (as extracted from logs generated by "org.apache.commons.httpclient.Wire
> wire").
> Formally thats OK, but in real world it is all about interoperability, and
> that is: about tolerance, as far as its clear what is "meant".
> Thus it would be nice to be able to deliberately "weaken" the validation
> process especially for the encoding: It should be possible to switch of the
> check of XML encoding setup against HTTP header encoding setup and instead
> simply use the XML encoding setup.
> Especially if a given remote service must be used, the client code
> implementer has no influence on what the service returns -- she simply has to
> arrange her code to match the given service. And in my case, this simply
> seems impossible with the released Axis2 1.4.1 client code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
