axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (JIRA)" <>
Subject [jira] Commented: (AXIS2-4386) Add some tolerance to BuilderUtil.validateCharSetEncoding()
Date Wed, 17 Jun 2009 07:50:07 GMT


Andreas Veithen commented on AXIS2-4386:

I think it's wrong to say that interoperability is about tolerance. Also, if the service returns
two conflicting pieces of information it is not clear at all what is "meant". Therefore I
don't think we should modify Axis2 to cope with this particular type of broken service.

Anyway, this is actually not necessary, because you can create your own replacement for org.apache.axis2.builder.SOAPBuilder
(which would be more lenient and work with the broken service) and register it in axis2.xml.

> Add some tolerance to BuilderUtil.validateCharSetEncoding()
> -----------------------------------------------------------
>                 Key: AXIS2-4386
>                 URL:
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Improvement
>          Components: client-api
>    Affects Versions: 1.4.1
>         Environment: IBM WebSphere Application Server / 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(
> 	at org.apache.axis2.builder.SOAPBuilder.processDocument(
> 	at org.apache.axis2.transport.TransportUtils.createDocumentElement(
> 	at org.apache.axis2.transport.TransportUtils.createSOAPMessage(
> 	at org.apache.axis2.transport.TransportUtils.createSOAPMessage(
> 	at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(
> 	at org.apache.axis2.description.OutInAxisOperationClient.send(
> 	at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(
> 	at org.apache.axis2.client.OperationClient.execute(
> [...]
> 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="" xmlns:soapenv=""
xmlns:xsd="" xmlns:xsi=""><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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message