#41097 [Asn->Csd]: ext/soap returning associative array as indexed without using WSDL

From: Date: Wed, 02 May 2007 08:22:42 +0000
Subject: #41097 [Asn->Csd]: ext/soap returning associative array as indexed without using WSDL
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-112159@lists.php.net to get a copy of this message
ID: 41097 Updated by: dmitry@php.net Reported By: r dot korving at xit dot nl -Status: Assigned +Status: Closed Bug Type: SOAP related Operating System: Debian PHP Version: 5.2.1 Assigned To: dmitry New Comment: Your expectation is wrong because PHP converts numeric string indeces into integer. $ sapi/cli/php -r 'var_dump(array("5" => "Foo", "10" => "Bar"));' array(2) { [5]=> string(3) "Foo" [10]=> string(3) "Bar" } BTW I fixed ext/soap to use Apache:Map instead of SOAP-ENC:Array in case of partial arrays (missing indeces). FIXED in CVS HEAD and PHP_5_2. Previous Comments: ------------------------------------------------------------------------ [2007-04-16 06:59:17] r dot korving at xit dot nl Description: ------------ Returning array('5' => 'Foo', '10' => 'Bar') from a SoapServer handler class ends up as array(0 => 'Foo', 1 => 'Bar') at the client end. But array('a' => 'Foo', 'b' => 'Bar') does end up correctly. It only fails with numeric keys. I'm not using WSDL in this case. I think integer keys that are not in a simple 0..n range should end up in an associative array, not indexed with new 0..n keys. Reproduce code: --------------- <?php class MyHandler { public function getData() { return array('5' => 'Foo', '10' => 'Bar'); } } // initialize soap-server: $soap = new SoapServer(null, array('uri' => 'http://uri/', 'encoding' => 'ISO-8859-1')); $soap->setClass('MyHandler'); $soap->handle(); ?> Expected result: ---------------- array('5' => 'Foo', '10' => 'Bar') Actual result: -------------- array(0 => 'Foo', 1 => 'Bar') ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=41097&edit=1

« previous php.bugs (#112159) next »