#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
