Php – WCF client proxy mishandling returned SOAP envelope

clientPHPsoapwcfwsdl

I have a RPC encoded PHP webservice that returns a simple soap envelope with a boolean datatype. When doing the trace on the client side, the soap envelope looks like this right before it goes into the WCF proxy:

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:ns1="http://sample.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENC="http://schemas.xmlsoap.org
/soap/encoding/">
  <SOAP-ENV:Body>
    <ns1:ServiceMessageResponse>
       <outgoingVar1>true</outgoingVar1>
    </ns1:ServiceMessageResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

However, when the returned value comes out the other side of the proxy it's been changed to false. I've tried adding an xsi:type="xsd:boolean" to the outgoingVar1, but that doesn't help. The soap envelope itself is exactly what the client should be expecting, but for some reason it won't consume it correctly. Is this something that has to do with the way the PHP web service is set up or is it in the WCF proxy? The PHP web service is simply set up like this:

ini_set('soap.wsdl_cache_enabled', '0');
ini_set('soap.wsdl_cache_ttl', '0');
$soapServer = new SoapServer('wsdl/sample.wsdl', array('soap_version' => SOAP_1_1));
$soapServer->addFunction('Service');
$soapServer->handle();

and the function ends with a simple 'return true;' line. Nothing complicated here. Any ideas what the problem may be?

The annotated WSDL (removed trivial namespaces and modified the real ones) looks like this:

<wsdl:definitions name="IJLSoapResponse" targetNamespace="http://casey.com"
tns="http://casey.com" xmlns:samp="http://sample.com" ...>
  <wsdl:types>
    <xsd:schema targetNamespace="http://casey.com" ...>
            <xsd:element name="incomingVar1" type="xsd:string" nillable="true"/>
            <xsd:element name="incomingVar2" type="xsd:string" nillable="true"/>
    </xsd:schema>
    <xsd:schema targetNamespace="http://sample.com" ...>
            <xsd:element name="outgoingVar1" type="xsd:boolean" nillable="true"/>
    </xsd:schema>
  </wsdl:types>
  <wsdl:message name="ServiceInput">
    <wsdl:part name="incomingVar1" element="tns:incomingVar1"/>
    <wsdl:part name="incomingVar2" element="tns:incomingVar2"/>
  </wsdl:message>
  <wsdl:message name="ServiceOutput">
    <wsdl:part name="outgoingVar1" element="samp:outgoingVar1"/>
  </wsdl:message>
  <wsdl:portType name="ServicePortType">
    <wsdl:operation name="ServiceMessage" parameterOrder="incomingVar1 incomingVar2">
            <wsdl:input name="ServiceMessageRequest" message="tns:ServiceInput"/>
            <wsdl:output name="ServiceMessageResponse" message="tns:ServiceOutput"/>
    </wsdl:operation>
  </wsdl:portType>
  <wsdl:binding name="ServiceBinding" type="tns:ServicePortType">
    <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="ServiceMessage">
            <soap:operation soapAction="http://casey.com/soap/Service"/>
            <wsdl:input name="ServiceMessageRequest">
                    <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://casey.com"/>
            </wsdl:input>
            <wsdl:output name="ServiceMessageResponse">
                    <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://sample.com"/>
            </wsdl:output>
    </wsdl:operation>
  </wsdl:binding>
  <wsdl:service name="ServiceService">
    <wsdl:port name="ServicePort" binding="tns:ServiceBinding">
            <soap:address location="http://casey.com/soap/Service"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

This should be enough to see how things are declared…let me know if you need anything else clarified. Thanks for your help!

Best Answer

May we see the WSDL of the service? I'm wondering what namespace outgoingVar1 is meant to be in.

RPC encoded services have always been a pain because of ambiguity about which namespace message parts are meant to be in. It won't surprise me to see that this is the problem here.

The following binding seems to work in soapUI. At least, it can generate a mock service, and the response message looks like what you were looking for (outgoingVar1 in sample namespace):

<wsdl:binding name="ServiceBinding" type="tns:ServicePortType">
    <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="ServiceMessage">
        <soap:operation soapAction="http://casey.com/soap/Service"/>
        <wsdl:input name="ServiceMessageRequest">
            <soap:body parts="incomingVar1 incomingVar2" use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://casey.com"/>
        </wsdl:input>
        <wsdl:output name="ServiceMessageResponse">
            <soap:body parts="outgoingVar1" use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://sample.com"/>
        </wsdl:output>
    </wsdl:operation>
</wsdl:binding>

Tracking it down

At first I thought this was a coercion bug where null was getting coerced to "null" and a test of "null" == null was passing. It's not. I was close, but so very, very wrong. Sorry about that!

I've since done lots of fiddling on wonderfl.net and tracing through the code in mx.rpc.xml.*. At line 1795 of XMLEncoder (in the 3.5 source), in setValue, all of the XMLEncoding boils down to

currentChild.appendChild(xmlSpecialCharsFilter(Object(value)));

which is essentially the same as:

currentChild.appendChild("null");

This code, according to my original fiddle, returns an empty XML element. But why?

Cause

According to commenter Justin Mclean on bug report FLEX-33664, the following is the culprit (see last two tests in my fiddle which verify this):

var thisIsNotNull:XML = <root>null</root>;
if(thisIsNotNull == null){
    // always branches here, as (thisIsNotNull == null) strangely returns true
    // despite the fact that thisIsNotNull is a valid instance of type XML
}

When currentChild.appendChild is passed the string "null", it first converts it to a root XML element with text null, and then tests that element against the null literal. This is a weak equality test, so either the XML containing null is coerced to the null type, or the null type is coerced to a root xml element containing the string "null", and the test passes where it arguably should fail. One fix might be to always use strict equality tests when checking XML (or anything, really) for "nullness."

Solution

The only reasonable workaround I can think of, short of fixing this bug in every damn version of ActionScript, is to test fields for "null" and escape them as CDATA values.

CDATA values are the most appropriate way to mutate an entire text value that would otherwise cause encoding/decoding problems. Hex encoding, for instance, is meant for individual characters. CDATA values are preferred when you're escaping the entire text of an element. The biggest reason for this is that it maintains human readability.

Best Answer

Related Solutions

Wcf – WsdlImporter Error when importing a wsdl from an ASMX web service

Actionscript – How to pass “Null” (a real surname!) to a SOAP web service in ActionScript 3

Tracking it down

Cause

Solution

Related Topic