Bug #48216 [Com]: PHP Fatal error: SOAP-ERROR: Parsing WSDL: Extra content at the end of the doc
Edit report at http://bugs.php.net/bug.php?id=48216&edit=1
ID: 48216
Comment by: derek dot ethier at humber dot ca
Reported by:mark at everytruckjob dot com
Summary:PHP Fatal error: SOAP-ERROR: Parsing WSDL: Extra
content at the end of the doc
Status: Open
Type: Bug
Package:SOAP related
Operating System: CentOs 5.3
PHP Version:5.3.0RC2
Block user comment: N
New Comment:
I'm experiencing the same issue with the following WSDL file:
https://qa.everbridge.net/ws3/services/WebServices3?wsdl
I'm using 5.2.13 on Windows Server 2008.
Here is the XML parsing error:
object(LibXMLError)#1 (6) {
["level"]=>
int(3)
["code"]=>
int(5)
["column"]=>
int(5)
["message"]=>
string(41) "Extra content at the end of the document
"
["file"]=>
string(56) "https://qa.everbridge.net/ws3/services/WebServices3?wsdl";
["line"]=>
int(537)
}
Previous Comments:
[2010-04-29 19:08:59] eaf at oyatel dot no
Wow, this is bad, still not fixed in PHP 5.3.2.
Can this please be fixed for PHP 5.3.3?
[2010-04-01 01:33:11] roy dot laurie at gmail dot com
Also, this is the current workaround that I'm using to get around this:
//+ral HACK: v5.3.x / libxml - http://bugs.php.net/bug.php?id=48216
//- $soapClient = new SoapClient("{$serviceUri}?wsdl", $soapOptions);
$tmpWsdlPath = tempnam(sys_get_temp_dir(), 'wsdl');
copy("{$serviceUri}?wsdl", $tmpWsdlPath);
$soapClient = new SoapClient($tmpWsdlPath, $soapOptions);
[2010-04-01 01:11:25] roy dot laurie at gmail dot com
Verified in 5.3.2 against the Yahoo! EWS service.
HTTP/1.1 200 OK
Date: Wed, 31 Mar 2010 23:04:51 GMT
p3p: policyref="http://p3p.yahoo.com/w3c/p3p.xml";, CP="CAO DSP COR CUR
ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi
PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"
Connection: close
Transfer-Encoding: chunked
Content-Type: text/xml;charset=utf-8
PHP 5.3.2 (cli) (built: Mar 5 2010 15:08:05)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
with Xdebug v2.0.5, Copyright (c) 2002-2008, by Derick Rethans
[2010-01-11 15:46:45] mike dot hall at twistdigital dot co dot uk
I'm having the same issue, also using chunked-encoding.
Date: Mon, 11 Jan 2010 15:44:23 GMT
Last-Modified: Fri, 09 Oct 2009 13:49:56 GMT
Accept-Ranges: bytes
Content-Type: text/xml
Cache-Control: private
Content-Encoding: gzip
Transfer-Encoding: chunked
[2010-01-08 20:02:28] mike at pixor dot net
I downloaded the 1/6/10 5.3.3-dev snapshot and was still having issues
with SOAP WSDL file parsing. 5.2.12 works fine. Please keep this issue
open.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=48216
--
Edit this bug report at http://bugs.php.net/bug.php?id=48216&edit=1
Bug #47716 [Com]: Invalid/Corrupt Math Convert string to float
Edit report at http://bugs.php.net/bug.php?id=47716&edit=1
ID: 47716
Comment by: derek dot ethier at humber dot ca
Reported by: codeslinger at compsalot dot com
Summary: Invalid/Corrupt Math Convert string to float
Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: windows 2000
PHP Version: 5.2.9
New Comment:
Cross-posting this with: http://bugs.php.net/bug.php?id=49764
It appears to happen randomly with either the number_format function or
with converting str to float. The only consistent element is that the
converted/formatted number contains a 9.
At least in my experience.
Previous Comments:
[2009-04-22 17:22:22] codeslinger at compsalot dot com
This is a copy of the comment that I put into Bug #47304 That bug has
now been closed due to lack of activity. So, we now have multiple
closed bugs, no fixes in sight, no further dev activity expected, and a
very serious problem remains.
---
Hi pajoye,
thank you for the response to bug #47716
you requested that future replies be here.
The interesting thing is that when you did a setlocale you got a result
back... but when I did it all I get is an empty string, I wondered
about this at the time that I entered the bug but did not mention it
because I figured the 18:0 vs 19.00 was sufficient.
and yes, as it states in that bug, the problem only occurs when a large
complex program using lots of memory is running and then within that
context you run the repro. if you just do the repro script by itself
with nothing else going on then it works just fine.
$arrMsgs[] = "Locale = ".setlocale(LC_ALL, "english-usa");
[0] => Locale =
I will give 5.3 a try and see what happens.
Environment: For the testing, I am actually running windows 2000 in a
vmware box under Ubuntu on a Pentium M.
-
P.S. my program has some dependencies on PECL libs, it turns out not to
be possible for me to run 5.3 at this time.
[2009-03-20 16:04:34] paj...@php.net
Please reply in #47304 (duplicated).
[2009-03-20 15:57:31] paj...@php.net
I'm not sure what's wrong.
Here is what I get:
Windows 2008 (latest SP):
Array
(
[0] => Locale = English_United States.1252
[1] => memory_get_peak_usage(true) = 262144
[2] => memory_get_peak_usage(false) = 58240
[3] => memory_get_usage(true) = 262144
[4] => memory_get_usage(false) = 57240
[5] => (float)19.00 = 19
[6] => (float)'19.00' = 19
[7] => round('19.00', 2) = 19
)
Windows 2003 (latest SP):
Array
(
[0] => Locale = English_United States.1252
[1] => memory_get_peak_usage(true) = 262144
[2] => memory_get_peak_usage(false) = 56152
[3] => memory_get_usage(true) = 262144
[4] => memory_get_usage(false) = 56024
[5] => (float)19.00 = 19
[6] => (float)'19.00' = 19
[7] => round('19.00', 2) = 19
)
Windows XP sp2:
Array
(
[0] => Locale = English_United States.1252
[1] => memory_get_peak_usage(true) = 262144
[2] => memory_get_peak_usage(false) = 57112
[3] => memory_get_usage(true) = 262144
[4] => memory_get_usage(false) = 56112
[5] => (float)19.00 = 19
[6] => (float)'19.00' = 19
[7] => round('19.00', 2) = 19
)
[2009-03-20 15:40:32] codeslinger at compsalot dot com
in case it wasn't clear from the description above, this is using the
CLI version of php.
also unlike a number of other bugs that I have read. Adding and
removing various lines of code -- which I did quite a bit of while
isolating this problem, plus adding a planned revision to the code --
had no effect on the result, the bug was totally repeatable.
This was using the official php windows binary, not one that I compiled.
The only difference between the working and not working versions of the
program are the php version.
How is it possible to convert a string to a float and have the result
contain a colon character???
[2009-03-19 12:11:23] codeslinger at compsalot dot com
Description:
It is with great hesitancy that I enter this bug, because I am not able
to produce a simple test case for it. But the bug is very serious.
I have a program that calculates and sends out customer statements.
Without making any changes to the php program itself which has been
running fine, I upgraded to PHP 5.2.9
Bug #49764 [Com]: number_format() fails (randomly?)
Edit report at http://bugs.php.net/bug.php?id=49764&edit=1 ID: 49764 Comment by: derek dot ethier at humber dot ca Reported by: tec at baufi24 dot de Summary: number_format() fails (randomly?) Status: Assigned Type: Bug Package: Math related Operating System: Windows Server 2003 RC2 PHP Version: 5.2.11 Assigned To: pajoye New Comment: I'm not sure if this will help at all, but outside of confirming this issue with number_format, it now appears as though converting a string to float causing a very similar problem. It seems to happen so randomly, but the only consistent element is that the numbers all have 9 in them. There is an existing bug opened for float that was closed as bogus: http://bugs.php.net/bug.php?id=47716 Previous Comments: [2010-04-16 11:15:26] paj...@php.net I will ask our test team to try to reproduce it. [2010-04-15 20:24:54] derek dot ethier at humber dot ca I've been experiencing a similar problem on 5.2.12 and 5.2.13 on a Windows Server 2003 environment (not R2). I haven't been able to nail down any sort of specifics as it happens so randomly. The only consistent element seems to centre around odd numbers (specifically with 9) format incorrectly in a similar manner to the one originally described (with a colon in the middle). I'm not sure if this helps at all, but I thought I'd add a comment anyway. [2009-12-21 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-12-13 18:13:29] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-10-12 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49764 -- Edit this bug report at http://bugs.php.net/bug.php?id=49764&edit=1
Bug #49764 [Com]: number_format() fails (randomly?)
Edit report at http://bugs.php.net/bug.php?id=49764&edit=1 ID: 49764 Comment by: derek dot ethier at humber dot ca Reported by: tec at baufi24 dot de Summary: number_format() fails (randomly?) Status: No Feedback Type: Bug Package: Math related Operating System: Windows Server 2003 RC2 PHP Version: 5.2.11 New Comment: I've been experiencing a similar problem on 5.2.12 and 5.2.13 on a Windows Server 2003 environment (not R2). I haven't been able to nail down any sort of specifics as it happens so randomly. The only consistent element seems to centre around odd numbers (specifically with 9) format incorrectly in a similar manner to the one originally described (with a colon in the middle). I'm not sure if this helps at all, but I thought I'd add a comment anyway. Previous Comments: [2009-12-21 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-12-13 18:13:29] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-10-12 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-10-04 18:03:36] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-10-04 08:55:27] tec at baufi24 dot de Description: Using number_format will sometimes produce a very hard error. This phenomenon is not persistent. Sometimes i will see that, but i dont know what conditions are necessary to reproduce Reproduce code: --- $value = 2900; echo "Unformated: ".$value.""; echo "Using number_format: ".number_format($value, 2, ',', '.').""; echo "Crosscheck: ".number_format(2900, 2, ',', '.').""; Expected result: Unformated: 2900 Using number_format: 2.900,00 Crosscheck: 2.900,00 Actual result: -- Unformated: 2900 Using number_format: 2.8:0,00 Crosscheck: 2.8:0,00 -- Edit this bug report at http://bugs.php.net/bug.php?id=49764&edit=1
#32564 [Com]: unset session in foreach
ID: 32564
Comment by: derek dot ethier at humber dot ca
Reported By: echenavaz at mengine dot fr
Status: Feedback
Bug Type: Session related
Operating System: debian 2.6.9
PHP Version: 5.0.4
New Comment:
More information:
This "problem" does not exist with 5.0.2 on Windows 2003 (IIS6).
duh at dowebwedo dot com's method does work within the execution of
that one script, but the unset variables are not persistent. The
$_SESSION variables are restored on each subsequent page load even
after they have been unset which leads to problems with session
fixation and the inability to clean-up session values that are no
longer needed.
Previous Comments:
[2005-04-04 18:56:56] derek dot ethier at humber dot ca
I can confirm this problem with Windows Server 2003, PHP 5.0.4. Sample
code:
$session_variable) {
if (strstr($session_key, $session_name)) {
// Neither of these work as intended.
unset($GLOBALS[_SESSION][$session_key]);
unset($_SESSION[$session_key]);
}
}
}
unsetSessionVariables("session_name");
?>
I have verified that the same problem exists in the latest 5.1 snap
(php5-win32-200504041430) on the same platform.
[2005-04-04 12:43:10] duh at dowebwedo dot com
I did not experience any problems with Apache/1.3.29 (Unix) PHP/5.0.4
on Debian stable.
Code:
$session)
unset($_SESSION[$key_session]);
print_r($_SESSION);
?>
Result is as expected:
Array ( [DF_debug] => 1 [one] => 1 [two] => 2 [three] => 3 ) Array ( )
[2005-04-04 10:23:51] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-04-04 10:17:18] echenavaz at mengine dot fr
Description:
work fine whith 5.0.0
do not work whith 5.0.4
(whith zlib.output_compression = On)
Reproduce code:
---
foreach($_SESSION as $key_session => $session)
{
if(substr($key_session, 0, 17) == "session_pm_search")
{
unset($_SESSION[$key_session]);
}
}
$forward_url =
"https://".$_SERVER['HTTP_HOST'].$_SERVER['SCRIPT_NAME'];
header("location:$forward_url");
die();
Expected result:
$_SESSION['session_pm_searchX'] are unset
Actual result:
--
$_SESSION['session_pm_searchX'] are not unset
--
Edit this bug report at http://bugs.php.net/?id=32564&edit=1
#32564 [Com]: unset session in foreach
ID: 32564
Comment by: derek dot ethier at humber dot ca
Reported By: echenavaz at mengine dot fr
Status: Feedback
Bug Type: Session related
Operating System: debian 2.6.9
PHP Version: 5.0.4
New Comment:
I can confirm this problem with Windows Server 2003, PHP 5.0.4. Sample
code:
$session_variable) {
if (strstr($session_key, $session_name)) {
// Neither of these work as intended.
unset($GLOBALS[_SESSION][$session_key]);
unset($_SESSION[$session_key]);
}
}
}
unsetSessionVariables("session_name");
?>
I have verified that the same problem exists in the latest 5.1 snap
(php5-win32-200504041430) on the same platform.
Previous Comments:
[2005-04-04 12:43:10] duh at dowebwedo dot com
I did not experience any problems with Apache/1.3.29 (Unix) PHP/5.0.4
on Debian stable.
Code:
$session)
unset($_SESSION[$key_session]);
print_r($_SESSION);
?>
Result is as expected:
Array ( [DF_debug] => 1 [one] => 1 [two] => 2 [three] => 3 ) Array ( )
[2005-04-04 10:23:51] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-04-04 10:17:18] echenavaz at mengine dot fr
Description:
work fine whith 5.0.0
do not work whith 5.0.4
(whith zlib.output_compression = On)
Reproduce code:
---
foreach($_SESSION as $key_session => $session)
{
if(substr($key_session, 0, 17) == "session_pm_search")
{
unset($_SESSION[$key_session]);
}
}
$forward_url =
"https://".$_SERVER['HTTP_HOST'].$_SERVER['SCRIPT_NAME'];
header("location:$forward_url");
die();
Expected result:
$_SESSION['session_pm_searchX'] are unset
Actual result:
--
$_SESSION['session_pm_searchX'] are not unset
--
Edit this bug report at http://bugs.php.net/?id=32564&edit=1
