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.
