|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #31832 SOAP encoding problem with complex types in WSDL mode with multiple parts
Submitted: 2005-02-03 20:14 UTC Modified: 2005-02-04 16:44 UTC
From: aws105 at york dot ac dot uk Assigned: dmitry
Status: Closed Package: SOAP related
PHP Version: 5.0.3 OS: FreeBSD, Gentoo Linux
Private report: No CVE-ID:
 [2005-02-03 20:14 UTC] aws105 at york dot ac dot uk
The SOAP extension handles the return of a single complex type perfectly (eg. the test script schema030.phpt) but the encoding changes if another part is added to the response. It looks like it is not able to get the type information from the WSDL correctly when there are multiple parts.

Consider a server exposing two functions, test1 and test2 via SOAP 1.1 using rpc/encoded style. Suppose the first returns the testType complex type from schema030.phpt (a sequence of an integer followed by a string) and the second returns two parts, the first a testType complex type and the second a simple type, say a string.

Simple client and server scripts are available (see attached) and operate in WSDL mode.

The SOAP response for test1 will be that expected in schema030.phpt. In particular the one return parameter is encoded as:
<testParam xsi:type="ns1:testType"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam>

Now the test2 simply adds a second part to the response so we expect:
<testParam xsi:type="ns1:testType"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam>
<strParam xsi:type="xsd:string">example</strParam>

but we actually get:
<testParam xsi:type="SOAP-ENC:Struct"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam>
<strParam xsi:type="xsd:string">example</strParam>

The xsi:type attribute of the testParam tag changes when an extra part is included in the message.

Similar behaviour occurs when the testParam part is changed to an array of the testType complex type: one part works fine but with two parts the array is encoded like:
<testParam xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="SOAP-ENC:Struct[1]"><item xsi:type="SOAP-ENC:Struct"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></item></testParam>
where again SOAP-ENC:Struct should be ns1:testType but also SOAP-ENC:Array should be ns1:ArrayOftestType where ArrayOftestType is defined as a restriction on SOAP-ENC:Array to only accept elements of type testType.

Note that one can work around this problem by creating a SoapParam object with a SoapVar object for the problem return part(s) as if in non-WSDL mode.

Reproduce code:
Simple client and server scripts are available for test at and
using the WSDL at

The source is available at and

Expected result:
The client should produce:
...<ns1:test1Response><testParam xsi:type="ns1:testType"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam></ns1:test1Response>...
...<ns1:test2Response><testParam xsi:type="ns1:testType"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam><strParam xsi:type="xsd:string">example</strParam></ns1:test2Response>...

Actual result:
The actual output observed is:
...<ns1:test1Response><testParam xsi:type="ns1:testType"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam></ns1:test1Response>...
...<ns1:test2Response><testParam xsi:type="SOAP-ENC:Struct"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam><strParam xsi:type="xsd:string">example</strParam></ns1:test2Response>...

Notice how the testParam xsi:type attribute changes between test1 and test2.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-02-04 12:04 UTC] aws105 at york dot ac dot uk
A little further investigation reveals that a similar issue occurs with user-defined simple types. Eg. a type defined as a restriction on the string type is serialized as a string in the response, not as the user defined type.

The serialization of user-defined types (both simple and complex) works correctly for the request.
 [2005-02-04 16:44 UTC]
Fixed in CVS (HEAD and PHP_5_0).
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Fri Jan 20 09:01:51 2017 UTC