|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #48717 Cannot pass datatype long (> 2147483647) in SOAP requests
Submitted: 2009-06-29 11:06 UTC Modified: 2010-10-27 20:46 UTC
Avg. Score:4.7 ± 0.4
Reproduced:21 of 21 (100.0%)
Same Version:7 (33.3%)
Same OS:7 (33.3%)
From: rob at zcore dot org Assigned:
Status: Open Package: SOAP related
PHP Version: 5.2.11 OS: Debian GNU/Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: rob at zcore dot org
New email:
PHP Version: OS:


 [2009-06-29 11:06 UTC] rob at zcore dot org
For some reason

    [0] => dummy Object
            [id] => 10047678003
            [pass] => XxX


is transformed to

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="" xmlns:ns1="">

while it's based on this XSD snipplet:

<xs:complexType name="authenticate">
<xs:element name="id" type="xs:long"></xs:element>
<xs:element name="pass" type="xs:string" minOccurs="0"></xs:element>

Expected result:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="" xmlns:ns1="">

Actual result:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="" xmlns:ns1="">


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-07-14 13:59 UTC] ghostbaer at gmx dot de

a very dirty workaround is to download the wsdl an rewrite it locally to another datatype. Changing this line:

<xs:element name="id" type="xs:long"></xs:element>


<xs:element name="id" type="xs:float"></xs:element>

should work at least. But it's a very, very, VERY, VERY, VEWY, VEWY, VEWYVEWYVEWY dirty workaround and you'll got to hell for this or even worse!
 [2009-07-15 14:18 UTC] rob at zcore dot org
Sorry, this one is way toooo dirty.
 [2009-09-25 16:42 UTC] persiancity at gmail dot com
I have the same problem ( ) but float replacement not working!
 [2009-09-25 16:51 UTC]
I can not reproduce it with PHP 5.2 HEAD. Can you check with a sniffer, or with __getLastRequest/Response if the error also occurs in the request?
 [2009-09-25 17:20 UTC] persiancity at gmail dot com
I am not pro in SOAP so maybe provide me __getLastRequest/Response testing code?
 [2009-09-25 17:23 UTC] persiancity at gmail dot com
another note:
I get corrent result sends from a server using PHP 5.2.42
Incorrect result sends from a server with PHP 5.2.9
 [2009-09-27 12:14 UTC] rob at zcore dot org

in the meantime my company upgraded to 5.2.11 (security reasons); the bug seems to be in there, too.

Unluckily updating to HEAD is no option, since we are using the ZendPlatform.

 [2009-09-28 08:19 UTC] smashles at gmail dot com
I experience a similar issue on latest FreeBSD+Apache-2.2.13+PHP5.2.11 whiling passing longint to a postgresql. When passing a number larger then maxint, it's reduced to 2147483647.
 [2009-09-28 19:12 UTC]
To properly diagnose this bug, we need the SOAP request and response. You can get that using a sniffer (Wireshark) or using __getLastRequest and __getLastResponse. See the PHP manual for information on these methods.
 [2010-10-27 20:05 UTC] periklis dot tsirakidis at mayflower dot de
Hey guys,

this serious bug is still damaging SOAP envelopes with long in there. We have the same problem on PHP 5.3.2 and 5.3.3 (32Bit) under Windows 2008R2 (64Bit) with IIS7. I think the bug reporter posted exactly the last request in order to fix this issue. Here is ours:

<SOAP-ENV:Envelope xmlns:SOAP-ENV=\"\" xmlns:ns1=\"\">

I believe that it is time to fix this loooong problem with long datatypes.

My 2 cents

 [2010-10-27 20:15 UTC]
PHP on windows uses 32bit integer for long, always. That's not possible to fix easily either.

Two choices, either convert to double when an integer overflow happens, or wait until we have big integer support.
 [2010-10-27 20:20 UTC] periklis dot tsirakidis at mayflower dot de
Ouch... Pierre, 

one serious notice is, that we changed the wsdl for <options> from xsd:long to xsd:string and the problem is still there. Do we have here an auto-casting from string to long?

Any ideas?
 [2010-10-27 20:46 UTC]

$a = "1234";
$b = 1234;

if ($a == $b) echo "hopla";

well known problem related to php auto casting, or better said, typeless.
 [2014-05-30 11:17 UTC] dev dot rindeal+bugs dot php dot net at outlook dot com
PHP 5.5.12 x86 on Windows 8 and it's still there. Thankfully the workaround in the comment #1 works for me. Thank you "ghostbaer at gmx dot de", you saved my work.
 [2016-10-28 11:54 UTC] perske at uni-muenster dot de
Even if you pass a huge integer as a string it is mixed up.

Reason: PHP 5.6.23, file ext/soap/php_encoding.c, function to_xml_long:

Line 1118:

                if (Z_TYPE(tmp) != IS_LONG) {

If a string is passed, it should not be converted to long and back to string loosing precision with very long integers.
 [2016-10-28 15:19 UTC] perske at uni-muenster dot de
Simple Fix:

In ext/soap/php_encoding.c, in all lines containing


i.e. for all XML data types containing integers of unlimited size,
replace "long" with "string", e.g.

        {{XSD_INTEGER, XSD_INTEGER_STRING, XSD_NAMESPACE, NULL}, to_zval_long, to_xml_long},


        {{XSD_INTEGER, XSD_INTEGER_STRING, XSD_NAMESPACE, NULL}, to_zval_string, to_xml_string},

This fix brings a minor incompatibility if somebody checks value and type of the result of a SOAP function.
(An alternative would be to add a function to_zval_long_or_string that returns an integer if it fits and otherwise a string.)
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Jul 24 15:01:29 2024 UTC