Home » Web Services » SOAP » Bug #4639

[2005-06-20 16:06 UTC] rhl at izzlazz dot dk

Description:
------------
This bug report is for SOAP version 0.9.1.

The code used to determine whether section 5 encoding should be enabled is wrong. Section 5 encoding should be enabled when encoded use is in effect, and disabled for literal use - the actual check is inverted.

Reproduce code:
---------------
I have not included a test case, but here is a patch that fixes the problem:

--- SOAP/Client.php.orig 2005-06-20 17:43:00.861828000 +0200
+++ SOAP/Client.php 2005-06-20 18:00:20.056212194 +0200
@@ -546,7 +546,7 @@

// Serialize the message.
$this->_section5 = (isset($this->__options['use']) &&
- $this->__options['use'] == 'literal');
+ $this->__options['use'] == 'encoded');

if (!isset($this->__options['style']) ||
$this->__options['style'] == 'rpc') {

With this patch applied, I can use a (proprietary) Java-based web service, which otherwise fails with an "Invalid date/time" exception on a dateTime parameter.

[2005-07-12 23:33 UTC] kstout at amplifier dot com

This bug prevents the use of any ASP.NET web service that takes an argument.

Here's a test case:

<?php
require_once 'SOAP/Client.php';

$wsdl = new SOAP_WSDL('http://www.jasongaylord.com/webservices/zipcodes.asmx?WSDL');

$client = $wsdl->getProxy();

print_r( $client->ZipCodeToDetails('78704'));
?>

it works when the fix described by rhl is in place and returns:

Server was unable to process request. --> Procedure 'GetDetailsForZipCode' expects parameter '@ZipCode', which was not supplied.

when it is not.

[2005-07-15 15:09 UTC] marcel dot berteler at bdsolutions dot co dot za

I have the same problem, but did not have internet while bug-fixing.

I had to talk to a .NET server and that was not working.

The bug-fix I used could probably introduc an other bug and the above mentioned fix is much nicer, but it worked for my specific case. (I still have to try the bug fix above)

in Client.php, the following line make _section5 TRUE if 'literal' is used:

// Serialize the message.
$this->_section5 = (isset($this->__options['use']) && $this->__options['use'] == 'literal');

In Base.php, the code checks if _section5 is FALSE, where the abbove code makes it TRUE. This clearly does not work.

/* If 'use' == 'literal', we do not put in the encodingStyle. This is
* denoted by $this->_section5 being false. 'use' can be defined at a
* more granular level than we are dealing with here, so this does not
* work for all services. */

I changed the client.php code to != and that worked. Is _section5 used in other parts of the code as well, or is this a proper fix?

-- $this->__options['use'] == 'literal');
++ $this->__options['use'] != 'literal');

[2005-07-18 18:26 UTC] jwm at horde dot net

I'll second this bug report; 0.8 set $this->_section5 = true when $this->__options['use'] was 'encoded', which is correct. 0.9 inverted this test, and now $this->_section5 is always the opposite of what it should be, as the initial reporter indicates. His patch works fine for me, and got PEAR::SOAP working with an ASP.NET(?) wrapped document/literal server.

[2005-12-14 19:55 UTC] jud at amplifier dot com

Yet another full day of two developers' lives have been consumed because you folks have decided that this *BUG* is not major enough to warrant a new release of this package!

PLEASE expedite the push of this release so other developers needing to integrate PHP with .NET via SOAP are spared this same miserable headache!

This crap makes open-source look real bad to the Microsloths out there.

Thanks.