#32117 [NEW]: ComplexType Encoding Incorrect
From: rtroll at yahoo-inc dot com Operating system: PHP version: 5CVS-2005-02-26 (dev) PHP Bug Type: SOAP related Bug description: ComplexType Encoding Incorrect Description: When encoding a complex array datatype (via a doc/literal request); the encoding is incorrect. The following code performs a request, and displays the request/response structures. The server is unable to locate the client supplied params, due to the request being (I believe) incorrect. Additionally, PHP appears to not be sending over array element 0 in this demo. Reproduce code: --- ?php $WSDL = http://ws1.api.re2.yahoo.com/ws/soap-demo/full.wsdl;; $DEBUG=true; $client = new SoapClient( $WSDL, array( trace = $DEBUG, exceptions = 0, )); function dump_xml( $title, $body ) { $nl = preg_replace( /\\/, \n, $body ); $clean = htmlspecialchars( $nl ); print \nb$title/b\npre$clean/pre\n; } $r = $client-strArrayReverse('This', 'is', 'a', 'test', '.'); dump_xml( Request, $client-__getLastRequest() ); dump_xml( Response, $client-__getLastResponse() ); ? Expected result: The request should be: ?xml version=1.0 encoding=UTF-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:ns1=urn:yahoo:platform:soap:demo:full SOAP-ENV:Body ns1:strArrayReverse ns1:saVal param0This/param0 param1is/param1 param2a/param2 param3test/param3 param4./param4 /ns1:saVal /ns1:strArrayReverse /SOAP-ENV:Body /SOAP-ENV:Envelope Note that the method being accessed (strArrayReverse) now contains a single arg (saVal), which is an array of 5 elements. Also note that param0 is present. This request will elicit the correct response from the server. Indent lines indicate lines that have been added, or changed, compared to the original request sent from PHP. Actual result: -- The request being generated by PHP's soap interface is: ?xml version=1.0 encoding=UTF-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:ns1=urn:yahoo:platform:soap:demo:full SOAP-ENV:Body ns1:strArrayReverse/ param1is/param1 param2a/param2 param3test/param3 param4./param4 /SOAP-ENV:Body /SOAP-ENV:Envelope -- Edit bug report at http://bugs.php.net/?id=32117edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32117r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32117r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32117r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32117r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32117r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32117r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32117r=needscript Try newer version: http://bugs.php.net/fix.php?id=32117r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32117r=support Expected behavior: http://bugs.php.net/fix.php?id=32117r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32117r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32117r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32117r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32117r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32117r=dst IIS Stability: http://bugs.php.net/fix.php?id=32117r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32117r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32117r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32117r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32117r=mysqlcfg
#32138 [NEW]: dateTime decoding: not present
From: rtroll at yahoo-inc dot com Operating system: PHP version: 5CVS-2005-02-28 (dev) PHP Bug Type: SOAP related Bug description: dateTime decoding: not present Description: When using the PHP SOAP client to send over a dateTime object; the client correctly turns a unix timestamp into the appropriate XML dateTime object. When using the PHP SOAP ext to write a SOAP service; the value is not decoded. Using the WSDL available via: http://ws1.api.re2.yahoo.com/ws/soap-demo/full-php.wsdl a PHP5 SOAP client will send a request containing a dateTime encoded entity: ns1:dtval2005-02-28T12:40:51-0800/ns1:dtval based on calling the function with a Unix timestamp: $client-dateInfo(array( 'dtval' = time() )); However, a PHP5 SOAP server receiving the request: ns1:dtval2005-02-28T12:40:51-0800/ns1:dtval does not decode the dateTime object into a time_t. Instead, it passes the raw value to the service method. Reproduce code: --- ?php $WSDL = http://ws1.api.re2.yahoo.com/ws/soap-demo/full-php.wsdl;; function dateInfo( $req ) { $dtval = $req-dtval; error_log(Returned $dtval, 0); return ( array( 'dateString' = no ctime function, 'dateSeconds' = $dtval )); } ini_set(soap.wsdl_cache_enabled, 0); // Disable WSDL caching $server = new SoapServer( $WSDL ); $server-addFunction(dateInfo); # 2 $server-handle(); ? Expected result: When using a SOAP client that hits the above script; I would expect the error log to contain: [...] [error] Returned 1234567890 instead, it's returning: [...] [error] Returned 2005-02-28T19:22:24Z -- Edit bug report at http://bugs.php.net/?id=32138edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32138r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32138r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32138r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32138r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32138r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32138r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32138r=needscript Try newer version: http://bugs.php.net/fix.php?id=32138r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32138r=support Expected behavior: http://bugs.php.net/fix.php?id=32138r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32138r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32138r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32138r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32138r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32138r=dst IIS Stability: http://bugs.php.net/fix.php?id=32138r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32138r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32138r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32138r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32138r=mysqlcfg
#32139 [NEW]: dateTime decoding: not present
From: rtroll at yahoo-inc dot com Operating system: PHP version: 5CVS-2005-02-28 (dev) PHP Bug Type: SOAP related Bug description: dateTime decoding: not present Description: When building a SOAP client or server that uses the base64Binary XML datatype, PHP is not performing the appropriate B64 encoding/decoding. When generating a SOAP client based on a WSDL, the PHP SOAP extension builds a collection of methods for me. These methods take args (as defined by the WSDL), and send them over the wire to the appropriate service. The extension takes care of encoding arrays as arrays, decimals as decimals, etc. If the item datatype is base64Binary, the extension does not b64 encode the value - it merely places it in the XML. This may be a feature, requiring client authors to read through the WSDL to determine what datatypes are being used, in order to adequately encode things before passing them into the autogenerated methods. If this is the appropriate functionality, the time_t - dateTime mapping should also be removed, providing a consistent, PHP does no data munging approach to generated interfaces. However, I'd much rather see the extension do the B64 encoding for me. :) Consider a service that returns an image: getImage(). It could be implemented such that the image is transmitted in b64 - but the client author shouldn't need to know that. Reproduce code: --- ?php $WSDL = http://ws1.api.re2.yahoo.com/ws/soap-demo/full.wsdl;; $SRCBUF = 1234567890abcdefghijklmnopqrstuvwxyz; $client = new SoapClient( $WSDL, array( trace = true, exceptions = 0, )); function dump_xml( $title, $body ) { $nl = preg_replace( /\\/, \n, $body ); $clean = htmlspecialchars( $nl ); print \nb$title/b\npre$clean/pre\n; } $r = $client-echoViaBase64( array( 'src' = $SRCBUF )); dump_xml( Request, $client-__getLastRequest() ); dump_xml( Response, $client-__getLastResponse() ); ? Expected result: The request generated by this PHP5 SOAP client contains the following body: SOAP-ENV:Body ns1:echoViaBase64 ns1:src1234567890abcdefghijklmnopqrstuvwxyz/ns1:src /ns1:echoViaBase64 /SOAP-ENV:Body Actual result: -- The request should look something like this: SOAP-ENV:Body ns1:echoViaBase64 ns1:srcMTIzNDU2Nzg5MGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6/ns1:src /ns1:echoViaBase64 /SOAP-ENV:Body -- Edit bug report at http://bugs.php.net/?id=32139edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32139r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32139r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32139r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32139r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32139r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32139r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32139r=needscript Try newer version: http://bugs.php.net/fix.php?id=32139r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32139r=support Expected behavior: http://bugs.php.net/fix.php?id=32139r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32139r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32139r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32139r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32139r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32139r=dst IIS Stability: http://bugs.php.net/fix.php?id=32139r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32139r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32139r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32139r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32139r=mysqlcfg
#32139 [Opn]: base64binary encode/decode
ID: 32139 User updated by: rtroll at yahoo-inc dot com -Summary: dateTime decoding: not present Reported By: rtroll at yahoo-inc dot com Status: Open Bug Type:SOAP related PHP Version: 5CVS-2005-02-28 (dev) New Comment: Changed summary. For some reason, summary kept the same value as my previously submitted bug. Previous Comments: [2005-02-28 22:02:00] rtroll at yahoo-inc dot com Description: When building a SOAP client or server that uses the base64Binary XML datatype, PHP is not performing the appropriate B64 encoding/decoding. When generating a SOAP client based on a WSDL, the PHP SOAP extension builds a collection of methods for me. These methods take args (as defined by the WSDL), and send them over the wire to the appropriate service. The extension takes care of encoding arrays as arrays, decimals as decimals, etc. If the item datatype is base64Binary, the extension does not b64 encode the value - it merely places it in the XML. This may be a feature, requiring client authors to read through the WSDL to determine what datatypes are being used, in order to adequately encode things before passing them into the autogenerated methods. If this is the appropriate functionality, the time_t - dateTime mapping should also be removed, providing a consistent, PHP does no data munging approach to generated interfaces. However, I'd much rather see the extension do the B64 encoding for me. :) Consider a service that returns an image: getImage(). It could be implemented such that the image is transmitted in b64 - but the client author shouldn't need to know that. Reproduce code: --- ?php $WSDL = http://ws1.api.re2.yahoo.com/ws/soap-demo/full.wsdl;; $SRCBUF = 1234567890abcdefghijklmnopqrstuvwxyz; $client = new SoapClient( $WSDL, array( trace = true, exceptions = 0, )); function dump_xml( $title, $body ) { $nl = preg_replace( /\\/, \n, $body ); $clean = htmlspecialchars( $nl ); print \nb$title/b\npre$clean/pre\n; } $r = $client-echoViaBase64( array( 'src' = $SRCBUF )); dump_xml( Request, $client-__getLastRequest() ); dump_xml( Response, $client-__getLastResponse() ); ? Expected result: The request generated by this PHP5 SOAP client contains the following body: SOAP-ENV:Body ns1:echoViaBase64 ns1:src1234567890abcdefghijklmnopqrstuvwxyz/ns1:src /ns1:echoViaBase64 /SOAP-ENV:Body Actual result: -- The request should look something like this: SOAP-ENV:Body ns1:echoViaBase64 ns1:srcMTIzNDU2Nzg5MGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6/ns1:src /ns1:echoViaBase64 /SOAP-ENV:Body -- Edit this bug report at http://bugs.php.net/?id=32139edit=1
#32115 [NEW]: dateTime encoding of timezone incorrect
From: rtroll at yahoo-inc dot com Operating system: PHP version: 5CVS-2005-02-25 (dev) PHP Bug Type: SOAP related Bug description: dateTime encoding of timezone incorrect Description: It looks like PHP's encoding of a dateTime value is incorrectly encoding the timezone. For example, encoding unix time: 1109366152 results in 2005-02-25T13:15:52-0800 instead of: 2005-02-25T13:15:52-08:00 The timezone offset must contain a colon, according to http://www.w3.org/TR/xmlschema-2/ Section 3.2.7.3: Timezones Reproduce code: --- ?php $WSDL = http://ws1.api.re2.yahoo.com/ws/soap-demo/full.wsdl;; $client = new SoapClient( $WSDL, array( trace = true, exceptions = 0, )); function dump_xml( $title, $body ) { $nl = preg_replace( /\\/, \n, $body ); $clean = htmlspecialchars( $nl ); print \nb$title/b\npre$clean/pre\n; } $t = time(); $r = $client-dateInfo( array( 'dtval' = $t ) ); $dateTime_pst = strftime( %Y-%m-%dT%H:%M:%S-08:00, time() ); # Works 'cause server is in PST zone $dateTime_utc = gmstrftime( %Y-%m-%dT%H:%M:%SZ, time() ); echo h2Bug/h2Request should have converted unix timestamp [$t] to xs:dateTime string [$dateTime_utc] or [$dateTime_pst]. Instead, request is:br\n; dump_xml( Request, $client-__getLastRequest() ); Expected result: Request should be similiar to: ?xml version=1.0 encoding=UTF-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:ns1=urn:yahoo:platform:soap:demo:full SOAP-ENV:Body ns1:dateInfo ns1:dtval2005-02-25T13:19:10-08:00/ns1:dtval /ns1:dateInfo /SOAP-ENV:Body /SOAP-ENV:Envelope Actual result: -- Request is currently: ?xml version=1.0 encoding=UTF-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:ns1=urn:yahoo:platform:soap:demo:full SOAP-ENV:Body ns1:dateInfo ns1:dtval2005-02-25T13:19:10-0800/ns1:dtval /ns1:dateInfo /SOAP-ENV:Body /SOAP-ENV:Envelope -- Edit bug report at http://bugs.php.net/?id=32115edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32115r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32115r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32115r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32115r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32115r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32115r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32115r=needscript Try newer version: http://bugs.php.net/fix.php?id=32115r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32115r=support Expected behavior: http://bugs.php.net/fix.php?id=32115r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32115r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32115r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32115r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32115r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32115r=dst IIS Stability: http://bugs.php.net/fix.php?id=32115r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32115r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32115r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32115r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32115r=mysqlcfg