#49716 [Fbk-Opn]: unable to fork using passthru, exec, system when executing page through iis
ID: 49716
User updated by: jbreiding at Hotmail dot com
Reported By: jbreiding at Hotmail dot com
-Status: Feedback
+Status: Open
Bug Type: IIS related
Operating System: windows server 2008 x64
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
unfortunately this is a production system now and i cannot test this at
the moment. i was hoping others had stumbled across this problem. my
future plans are just to move this entire system to a redhat box.
Previous Comments:
[2009-09-29 21:09:32] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-09-29 20:54:10] jbreiding at Hotmail dot com
Description:
i am no longer running this configuration as i found that moving back
to 5.2.11 solved this problem.
php 5.3.2 (x86 fastcgi)
windows server 2k8 (x64)
I have spent a good few days googling around and trying things so let
me give you the current state.
cmd.exe copied to php folder, all instances of cmd.exe, including
syswow64, given read execute permissions to domain users, local users,
iis_iusrs, network service in addition to the defaults
from my users command prompt i can execute php
c:\inetpub\wwwroot\forktest.php, as well the same with php-cgi -f
c:\inetpub\wwwroot\forktest.php
system() is giving a return_val of -1
in procmon.exe i can actually see the create call succeed. the
application being executed has also been given the same permissions as
cmd.exe, however it is not in the php folder but the full path has been
given.
my application pool, default setup, runs under network service.
here is a snippet that is failing from forktest.php
?php
$result = 0;
$resultstr = system('echo %PATH%', $result);
echo return value is $result \n;
echo output string is $resultstr \n;
?
output:
Warning: system() [function.system]: Unable to fork [echo %PATH%] in
C:\inetpub\wwwroot\forktest.php on line 25
return value is -1 output string is
i went ahead and deleted the cmd.exe in my php folder and in procmon i
am seeing exactly what should be happening,
c:\windows\syswow64\cmd.exe.
it seems my problem is actually executing cmd.exe, not the application
i am attempting to execute.
Reproduce code:
---
?php
$result = 0;
$resultstr = system('echo %PATH%', $result);
echo return value is $result \n;
echo output string is $resultstr \n;
?
--
Edit this bug report at http://bugs.php.net/?id=49716edit=1
#48779 [Com]: Use of HOST section cause 500 error
ID: 48779 Comment by: keithdavis at pridedallas dot com Reported By: keithdavis at pridedallas dot com Status: Open Bug Type: PHP options/info functions Operating System: Windows Vista Business x86 PHP Version: 5.3.0 New Comment: And it also happens for me on IIS6 (Server 2003.) Previous Comments: [2009-10-06 21:20:40] keithdavis at pridedallas dot com FYI, this happens with the PATH section enabled as well. [2009-07-07 09:34:02] paj...@php.net I was not able to reproduce the HOST issue. The backtrace does not crash in php_ini.c but before. [2009-07-07 01:16:03] scott...@php.net I tried to reproduce this on OSX and Linux without luck. The error looks like it's in main/php_ini.c from the backtrace, but I'm not sure whats up with the zval. [2009-07-06 23:13:37] keithdavis at pridedallas dot com I didn't even see that. I tried to follow those directions. Hopefully, they can figure it out from yours. [2009-07-06 22:55:30] paj...@php.net I already provided one. But if you can provide one for your case, see http://bugs.php.net/bugs-generating-backtrace-win32.php Maybe you catched another issue than the one I used. 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/48779 -- Edit this bug report at http://bugs.php.net/?id=48779edit=1
#49716 [Opn-Bgs]: unable to fork using passthru, exec, system when executing page through iis
ID: 49716
Updated by: paj...@php.net
Reported By: jbreiding at Hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: IIS related
Operating System: windows server 2008 x64
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
OK, anyway this bug is fixed and there was already another bug report
about it. I close it as duplicated (bogus).
Previous Comments:
[2009-10-06 20:26:04] jbreiding at Hotmail dot com
unfortunately this is a production system now and i cannot test this at
the moment. i was hoping others had stumbled across this problem. my
future plans are just to move this entire system to a redhat box.
[2009-09-29 21:09:32] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-09-29 20:54:10] jbreiding at Hotmail dot com
Description:
i am no longer running this configuration as i found that moving back
to 5.2.11 solved this problem.
php 5.3.2 (x86 fastcgi)
windows server 2k8 (x64)
I have spent a good few days googling around and trying things so let
me give you the current state.
cmd.exe copied to php folder, all instances of cmd.exe, including
syswow64, given read execute permissions to domain users, local users,
iis_iusrs, network service in addition to the defaults
from my users command prompt i can execute php
c:\inetpub\wwwroot\forktest.php, as well the same with php-cgi -f
c:\inetpub\wwwroot\forktest.php
system() is giving a return_val of -1
in procmon.exe i can actually see the create call succeed. the
application being executed has also been given the same permissions as
cmd.exe, however it is not in the php folder but the full path has been
given.
my application pool, default setup, runs under network service.
here is a snippet that is failing from forktest.php
?php
$result = 0;
$resultstr = system('echo %PATH%', $result);
echo return value is $result \n;
echo output string is $resultstr \n;
?
output:
Warning: system() [function.system]: Unable to fork [echo %PATH%] in
C:\inetpub\wwwroot\forktest.php on line 25
return value is -1 output string is
i went ahead and deleted the cmd.exe in my php folder and in procmon i
am seeing exactly what should be happening,
c:\windows\syswow64\cmd.exe.
it seems my problem is actually executing cmd.exe, not the application
i am attempting to execute.
Reproduce code:
---
?php
$result = 0;
$resultstr = system('echo %PATH%', $result);
echo return value is $result \n;
echo output string is $resultstr \n;
?
--
Edit this bug report at http://bugs.php.net/?id=49716edit=1
#49797 [Opn-Fbk]: strnatcmp and strings ending with 0
ID: 49797
Updated by: paj...@php.net
Reported By: j dot henge-ernst at interexa dot de
-Status: Open
+Status: Feedback
Bug Type: Strings related
Operating System: linux
PHP Version: 5.3.0
New Comment:
Pls see #44929 and try a snapshot as well.
Previous Comments:
[2009-10-06 21:55:55] j dot henge-ernst at interexa dot de
Description:
strnatcmp returns wrong results when one string is ending with a zero.
At leat in php 5.2.9 the expected result is returned. In php 5.3.0 and
5.2.10 it is broken.
Reproduce code:
---
?php
echo strnatcmp('b0', 'b0$') . \n;
echo strnatcmp('b1', 'b1$') . \n;
echo strnatcmp('b0x', 'b0x$') . \n;
echo strnatcasecmp('b0', 'B0$') . \n;
echo strnatcasecmp('b1', 'B1$') . \n;
echo strnatcasecmp('b0x', 'B0x$') . \n;
Expected result:
-1
-1
-1
-1
-1
-1
Actual result:
--
1
-1
-1
1
-1
-1
--
Edit this bug report at http://bugs.php.net/?id=49797edit=1
#49797 [NEW]: strnatcmp and strings ending with 0
From: j dot henge-ernst at interexa dot de
Operating system: linux
PHP version: 5.3.0
PHP Bug Type: Strings related
Bug description: strnatcmp and strings ending with 0
Description:
strnatcmp returns wrong results when one string is ending with a zero. At
leat in php 5.2.9 the expected result is returned. In php 5.3.0 and 5.2.10
it is broken.
Reproduce code:
---
?php
echo strnatcmp('b0', 'b0$') . \n;
echo strnatcmp('b1', 'b1$') . \n;
echo strnatcmp('b0x', 'b0x$') . \n;
echo strnatcasecmp('b0', 'B0$') . \n;
echo strnatcasecmp('b1', 'B1$') . \n;
echo strnatcasecmp('b0x', 'B0x$') . \n;
Expected result:
-1
-1
-1
-1
-1
-1
Actual result:
--
1
-1
-1
1
-1
-1
--
Edit bug report at http://bugs.php.net/?id=49797edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49797r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49797r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49797r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49797r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49797r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49797r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49797r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49797r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49797r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49797r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49797r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49797r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49797r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49797r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49797r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49797r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49797r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49797r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49797r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49797r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49797r=mysqlcfg
#49800 [NEW]: SimpleXML allow serialize() calls without warning
From: wmeler at wp-sa dot pl
Operating system: any
PHP version: 5.3.0
PHP Bug Type: SimpleXML related
Bug description: SimpleXML allow serialize() calls without warning
Description:
simplexml allows serialization which can (and should) be easily forbidden
with following patch
--- php-5.3.0/ext/simplexml/simplexml.c 2009-06-11 11:41:15.0
+0200
+++ arisphp5/php/ext/simplexml/simplexml.c 2009-10-06
18:39:54.000652000 +0200
@@ -2526,6 +2526,8 @@
sxe_class_entry = zend_register_internal_class(sxe TSRMLS_CC);
sxe_class_entry-get_iterator = php_sxe_get_iterator;
sxe_class_entry-iterator_funcs.funcs = php_sxe_iterator_funcs;
+ sxe_class_entry-serialize = zend_class_serialize_deny;
+ sxe_class_entry-unserialize = zend_class_unserialize_deny;
zend_class_implements(sxe_class_entry TSRMLS_CC, 1,
zend_ce_traversable);
sxe_object_handlers.get_method =
zend_get_std_object_handlers()-get_method;
sxe_object_handlers.get_constructor =
zend_get_std_object_handlers()-get_constructor;
Reproduce code:
---
?
echo serialize(simplexml_load_string(xml/));
Expected result:
Exception: Serialization of 'SimpleXMLElement' is not allowed in ...
Actual result:
--
O:16:SimpleXMLElement:0:{}
--
Edit bug report at http://bugs.php.net/?id=49800edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49800r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49800r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49800r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49800r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49800r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49800r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49800r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49800r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49800r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49800r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49800r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49800r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49800r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49800r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49800r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49800r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49800r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49800r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49800r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49800r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49800r=mysqlcfg
#49797 [Fbk-Csd]: strnatcmp and strings ending with 0
ID: 49797
User updated by: j dot henge-ernst at interexa dot de
Reported By: j dot henge-ernst at interexa dot de
-Status: Feedback
+Status: Closed
Bug Type: Strings related
Operating System: linux
PHP Version: 5.3.0
New Comment:
Snapshot php53-200910070830 and php52-200910070830 work as expected
Previous Comments:
[2009-10-07 08:13:11] paj...@php.net
Pls see #44929 and try a snapshot as well.
[2009-10-06 21:55:55] j dot henge-ernst at interexa dot de
Description:
strnatcmp returns wrong results when one string is ending with a zero.
At leat in php 5.2.9 the expected result is returned. In php 5.3.0 and
5.2.10 it is broken.
Reproduce code:
---
?php
echo strnatcmp('b0', 'b0$') . \n;
echo strnatcmp('b1', 'b1$') . \n;
echo strnatcmp('b0x', 'b0x$') . \n;
echo strnatcasecmp('b0', 'B0$') . \n;
echo strnatcasecmp('b1', 'B1$') . \n;
echo strnatcasecmp('b0x', 'B0x$') . \n;
Expected result:
-1
-1
-1
-1
-1
-1
Actual result:
--
1
-1
-1
1
-1
-1
--
Edit this bug report at http://bugs.php.net/?id=49797edit=1
#49797 [Csd-Bgs]: strnatcmp and strings ending with 0
ID: 49797
Updated by: paj...@php.net
Reported By: j dot henge-ernst at interexa dot de
-Status: Closed
+Status: Bogus
Bug Type: Strings related
Operating System: linux
PHP Version: 5.3.0
New Comment:
duplicate of #44929, which is fixed bogus.
Previous Comments:
[2009-10-07 09:59:56] j dot henge-ernst at interexa dot de
Snapshot php53-200910070830 and php52-200910070830 work as expected
[2009-10-07 08:13:11] paj...@php.net
Pls see #44929 and try a snapshot as well.
[2009-10-06 21:55:55] j dot henge-ernst at interexa dot de
Description:
strnatcmp returns wrong results when one string is ending with a zero.
At leat in php 5.2.9 the expected result is returned. In php 5.3.0 and
5.2.10 it is broken.
Reproduce code:
---
?php
echo strnatcmp('b0', 'b0$') . \n;
echo strnatcmp('b1', 'b1$') . \n;
echo strnatcmp('b0x', 'b0x$') . \n;
echo strnatcasecmp('b0', 'B0$') . \n;
echo strnatcasecmp('b1', 'B1$') . \n;
echo strnatcasecmp('b0x', 'B0x$') . \n;
Expected result:
-1
-1
-1
-1
-1
-1
Actual result:
--
1
-1
-1
1
-1
-1
--
Edit this bug report at http://bugs.php.net/?id=49797edit=1
#49800 [Opn-Csd]: SimpleXML allow serialize() calls without warning
ID: 49800
Updated by: il...@php.net
Reported By: wmeler at wp-sa dot pl
-Status: Open
+Status: Closed
Bug Type: SimpleXML related
Operating System: any
PHP Version: 5.3.0
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2009-10-07 12:46:30] s...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revisionrevision=289279
Log: Fixed bug #49800 (SimpleXML allow (un)serialize() calls without
warning).
# original patch by wmeler at wp-sa dot pl
[2009-10-07 09:09:44] wmeler at wp-sa dot pl
Description:
simplexml allows serialization which can (and should) be easily
forbidden with following patch
--- php-5.3.0/ext/simplexml/simplexml.c 2009-06-11 11:41:15.0
+0200
+++ arisphp5/php/ext/simplexml/simplexml.c 2009-10-06
18:39:54.000652000 +0200
@@ -2526,6 +2526,8 @@
sxe_class_entry = zend_register_internal_class(sxe
TSRMLS_CC);
sxe_class_entry-get_iterator = php_sxe_get_iterator;
sxe_class_entry-iterator_funcs.funcs =
php_sxe_iterator_funcs;
+ sxe_class_entry-serialize = zend_class_serialize_deny;
+ sxe_class_entry-unserialize = zend_class_unserialize_deny;
zend_class_implements(sxe_class_entry TSRMLS_CC, 1,
zend_ce_traversable);
sxe_object_handlers.get_method =
zend_get_std_object_handlers()-get_method;
sxe_object_handlers.get_constructor =
zend_get_std_object_handlers()-get_constructor;
Reproduce code:
---
?
echo serialize(simplexml_load_string(xml/));
Expected result:
Exception: Serialization of 'SimpleXMLElement' is not allowed in ...
Actual result:
--
O:16:SimpleXMLElement:0:{}
--
Edit this bug report at http://bugs.php.net/?id=49800edit=1
#45120 [Opn]: PDOStatement-execute() returns true then false for same statement
ID: 45120
Updated by: mbecc...@php.net
Reported By: morrisdavidd at gmail dot com
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3
New Comment:
The bug is reproducible only with the MySQL driver when using emulated
prepared queries, which is the default. I've tested PgSQL and Sqlite and
both work as expected.
There's also a pdo_mysql test for it, already marked as XFAIL:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/pdo_mysql/tests/bug_45120.phpt?view=markup
Previous Comments:
[2009-07-28 07:10:10] morrisdavidd at gmail dot com
Sorry for the late reply,
I just duplicated this bug in PHP 5.3
Cheers,
David)
[2009-05-03 01:00:13] 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-04-25 15:03:12] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-10-14 13:06:53] fel...@php.net
I can't reproduce it.
[2008-07-03 13:32:37] u...@php.net
On the first look this seems to be a PDO not a PDO_MYSQL (or any other
driver) bug.
From pdo_stmt.c, static PHP_METHOD(PDOStatement, execute), around line
450:
if (PDO_PLACEHOLDER_NONE == stmt-supports_placeholders) {
/* handle the emulated parameter binding,
* stmt-active_query_string holds the query with binds
expanded and
* quoted.
*/
ret = pdo_parse_params(stmt, stmt-query_string,
stmt-query_stringlen,
stmt-active_query_string,
stmt-active_query_stringlen
TSRMLS_CC);
[...]
}
For some drivers, PDO assigns the return value of its
pdo_parse_params() function to ret. And then the code flow continues and
eventually the driver gets called to execute the statement (depending on
the driver features):
if (stmt-methods-executer(stmt TSRMLS_CC)) {
if (stmt-active_query_string stmt-active_query_string !=
stmt-query_string) {
efree(stmt-active_query_string);
}
stmt-active_query_string = NULL;
if (!stmt-executed) {
/* this is the first execute */
if (stmt-dbh-alloc_own_columns !stmt-columns) {
/* for big boy drivers, we need to allocate
memory to fetch
* the results into, so lets do that now */
ret = pdo_stmt_describe_columns(stmt TSRMLS_CC);
}
stmt-executed = 1;
}
if (ret !dispatch_param_event(stmt, PDO_PARAM_EVT_EXEC_POST
TSRMLS_CC)) {
RETURN_FALSE;
}
RETURN_BOOL(ret);
}
ret (returned ny pdo_parse_params()) will be overwritten only on the
first execution. Upon subsequent executions the driver cannot set ret.
You get a bool(false) because pdo_parse_params() has returned 0 (=
success) and the return value of PDO_MYSQL has been ignored.
Maybe it should read like this:
if (ret = stmt-methods-executer(stmt TSRMLS_CC)) {
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/45120
--
Edit this bug report at http://bugs.php.net/?id=45120edit=1
#49226 [Com]: SoapServer failing on construction (cannot load wsdl)
ID: 49226
Comment by: petro at eps1lon dot com
Reported By: richard at rjharrison dot org
Status: Feedback
Bug Type: SOAP related
Operating System: linux
PHP Version: 5.3.0
New Comment:
I was having the same problem with SoapClient under 5.3.0. It is
working fine under 5.3.RC1.
Previous Comments:
[2009-10-01 11:37:09] sjo...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-09-30 18:26:54] sjo...@php.net
Evrard mailed me a HTTP trace, which I put here:
http://pastebin.com/f25b554f9
I could reproduce this with PHP 5.3, not PHP 5.3-HEAD, so this may have
already been fixed in trunk.
[2009-09-23 09:13:56] evrard at h2a dot lu
For everybody that are looking for a little fix for that, force
SoapClient to send an HTTP 1.0 request and your script may run again. It
is working for me with PHP 5.3.0, ZEND 1.9 (minimal package, via PEAR)
and APACHE 2.2.12 on Windows XP.
?php
try
{
$context = stream_context_create( array(
'http' = array(
'protocol_version'= '1.0' ,
'header'= 'Content-Type: text/xml;' ,
),
) );
$options = array(
'stream_context' = $context ,
);
$client = new SoapClient( 'http://myserver/path?wsdl' , $options
);
}
catch( Exception $e )
{
// You should not be here anymore
}
?
[2009-09-01 08:07:04] sjo...@php.net
Bug #49397 describes the same problem, but with SoapClient.
[2009-09-01 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/49226
--
Edit this bug report at http://bugs.php.net/?id=49226edit=1
#49226 [Com]: SoapServer failing on construction (cannot load wsdl)
ID: 49226
Comment by: petro at eps1lon dot com
Reported By: richard at rjharrison dot org
Status: Feedback
Bug Type: SOAP related
Operating System: linux
PHP Version: 5.3.0
New Comment:
That should be 5.3.1RC1.
Previous Comments:
[2009-10-07 16:25:01] petro at eps1lon dot com
I was having the same problem with SoapClient under 5.3.0. It is
working fine under 5.3.RC1.
[2009-10-01 11:37:09] sjo...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-09-30 18:26:54] sjo...@php.net
Evrard mailed me a HTTP trace, which I put here:
http://pastebin.com/f25b554f9
I could reproduce this with PHP 5.3, not PHP 5.3-HEAD, so this may have
already been fixed in trunk.
[2009-09-23 09:13:56] evrard at h2a dot lu
For everybody that are looking for a little fix for that, force
SoapClient to send an HTTP 1.0 request and your script may run again. It
is working for me with PHP 5.3.0, ZEND 1.9 (minimal package, via PEAR)
and APACHE 2.2.12 on Windows XP.
?php
try
{
$context = stream_context_create( array(
'http' = array(
'protocol_version'= '1.0' ,
'header'= 'Content-Type: text/xml;' ,
),
) );
$options = array(
'stream_context' = $context ,
);
$client = new SoapClient( 'http://myserver/path?wsdl' , $options
);
}
catch( Exception $e )
{
// You should not be here anymore
}
?
[2009-09-01 08:07:04] sjo...@php.net
Bug #49397 describes the same problem, but with SoapClient.
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/49226
--
Edit this bug report at http://bugs.php.net/?id=49226edit=1
#49803 [NEW]: OCI statement cache causes ORA-01007
From: stronk7 at moodle dot org Operating system: MacOS X (any) PHP version: 5.2.11 PHP Bug Type: OCI8 related Bug description: OCI statement cache causes ORA-01007 Description: Under certain circumstances (multiple DDL creation) OCI client statement cache causes ORA-01007: variable not in select list error in simple queries against those tables. Only disabling the cache ( oci8.statement_cache_size = 0 in php.ini, from default 20) alleviates the problem. Running with cache disabled has a big impact in oci performance. It should be some explicit way to clean the cache from php oci or the driver itself should be clever enough to clean it when DDL statements are executed. Reproduce code: --- http://tracker.moodle.org/secure/attachment/18556/testing_oci_stmt_cache_pureoci.php Expected result: TESTING MOODLE 2.0 OCI DRIVER WITH oci8.statement_cache_size = 0 (from php.ini) Created table unit_table (id, course, name). Ok Selected 0 records from table. Ok Dropped table unit_table (id, course, name). Ok Created table unit_table (id, course). Ok Selected 0 records from table. Ok Dropped table unit_table (id, course). Ok Actual result: -- TESTING MOODLE 2.0 OCI DRIVER WITH oci8.statement_cache_size = 20 (from php.ini) Created table unit_table (id, course, name). Ok Selected 0 records from table. Ok Dropped table unit_table (id, course, name). Ok Created table unit_table (id, course). Ok Error selecting records from table!! ORA-01007: variable not in select list Dropped table unit_table (id, course). Ok -- Edit bug report at http://bugs.php.net/?id=49803edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49803r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49803r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49803r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49803r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49803r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49803r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49803r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49803r=needscript Try newer version: http://bugs.php.net/fix.php?id=49803r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49803r=support Expected behavior: http://bugs.php.net/fix.php?id=49803r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49803r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49803r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49803r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49803r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49803r=dst IIS Stability: http://bugs.php.net/fix.php?id=49803r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49803r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49803r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49803r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49803r=mysqlcfg
#49753 [Com]: Current directory in shutdown function leaks between requests
ID: 49753
Comment by: ant at specialops dot ath dot cx
Reported By: ant at specialops dot ath dot cx
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Linux 2.6.30 (gentoo)
PHP Version: 5.3.0
New Comment:
I've just tested it, and it does indeed fix the problem.
Previous Comments:
[2009-10-04 15:21:57] ka...@php.net
We could store the cwd before trying to execute the shutdown handlers,
and then restore it to that dir after the handlers are executed. However
I'm not sure whether we should do this on per SAPI level or per function
implementation level, below patch patches it per function level.
Could you try apply this and see if it solves the problem?
Index: basic_functions.c
===
--- basic_functions.c (revision 289184)
+++ basic_functions.c (working copy)
@@ -5026,10 +5026,17 @@
void php_call_shutdown_functions(TSRMLS_D) /* {{{ */
{
if (BG(user_shutdown_function_names)) {
+ char *cwd = getcwd(NULL, 0);
+
zend_try {
zend_hash_apply(BG(user_shutdown_function_names),
(apply_func_t)
user_shutdown_function_call TSRMLS_CC);
}
zend_end_try();
+
+ if (cwd) {
+ chdir(cwd);
+ }
+
php_free_shutdown_functions(TSRMLS_C);
}
}
[2009-10-02 19:00:37] ant at specialops dot ath dot cx
Description:
In 5.3.0 one of my scripts stopped working due to the behaviour
documented at the bottom of the register_shutdown_function page.
The actual problem is that if I change the directory in the shutdown
function, that change persists across requests and can end up in
completely unrelated scripts' shutdown function calls.
Reproduce code:
---
?php
echo Script A\n;
function test() {
echo getcwd() . \n;
if ( file_exists('file.inc') ) {
include 'file.inc';
}
}
register_shutdown_function('test');
?
?php
echo Script B\n;
function change() {
chdir('/tmp/');
file_put_contents('file.inc', '?php echo something nasty\n;
?');
}
register_shutdown_function('change');
?
Expected result:
Script A
/var/www/localhost/htdocs/
Script B
Script A
/var/www/localhost/htdocs/
Actual result:
--
Script A
/var/www/localhost/htdocs/
Script B
Script A
/tmp
something nasty
--
Edit this bug report at http://bugs.php.net/?id=49753edit=1
#49804 [NEW]: cannot use [...] after a function returning array
From: valerio dot giuffrida88 at gmail dot com Operating system: ubuntu PHP version: 5.2SVN-2009-10-07 (snap) PHP Bug Type: Compile Failure Bug description: cannot use [...] after a function returning array Description: If i want to get an element of an array directly returned by a function, using [], it will prints Parse error: syntax error, unexpected '[', expecting ',' or ';' in php shell code on line 1 Reproduce code: --- $a = array(a,b,c); echo array_values($a)[0]; //it (doesnt) works with any function that retuns an array Expected result: print to screen something like that: a Actual result: -- Parse error: syntax error, unexpected '[', expecting ',' or ';' in php shell code on line 1 -- Edit bug report at http://bugs.php.net/?id=49804edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49804r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49804r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49804r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49804r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49804r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49804r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49804r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49804r=needscript Try newer version: http://bugs.php.net/fix.php?id=49804r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49804r=support Expected behavior: http://bugs.php.net/fix.php?id=49804r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49804r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49804r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49804r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49804r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49804r=dst IIS Stability: http://bugs.php.net/fix.php?id=49804r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49804r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49804r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49804r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49804r=mysqlcfg
#49804 [Opn-Bgs]: cannot use [...] after a function returning array
ID: 49804 Updated by: der...@php.net Reported By: valerio dot giuffrida88 at gmail dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: ubuntu PHP Version: 5.2SVN-2009-10-07 (snap) New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . Previous Comments: [2009-10-07 17:11:50] valerio dot giuffrida88 at gmail dot com Description: If i want to get an element of an array directly returned by a function, using [], it will prints Parse error: syntax error, unexpected '[', expecting ',' or ';' in php shell code on line 1 Reproduce code: --- $a = array(a,b,c); echo array_values($a)[0]; //it (doesnt) works with any function that retuns an array Expected result: print to screen something like that: a Actual result: -- Parse error: syntax error, unexpected '[', expecting ',' or ';' in php shell code on line 1 -- Edit this bug report at http://bugs.php.net/?id=49804edit=1
#48764 [Fbk-Csd]: PDO_pgsql::query always uses implicit prepared statements if v3 proto available
ID: 48764
Updated by: mbecc...@php.net
Reported By: mark dot kirkwood at catalyst dot net dot nz
-Status: Feedback
+Status: Closed
Bug Type: PDO related
Operating System: Linux 2.6.28 (Ubuntu) amd64
PHP Version: 5.3CVS-2009-07-01 (snap)
Assigned To: mbeccati
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2009-10-07 17:42:44] mbecc...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-10-07 17:40:17] s...@php.net
Automatic comment from SVN on behalf of mbeccati
Revision: http://svn.php.net/viewvc/?view=revisionrevision=289287
Log: - Fixed bug #48764 (PDO_pgsql::query always uses implicit prepared
statements if v3 proto available)
# original patch by Mark Kirkwood
[2009-08-13 05:22:17] mark dot kirkwood at catalyst dot net dot nz
new patch that handles PDO::ATTR_EMULATE_PREPARES as well
diff -Nacr php5.2-200908130230/ext/pdo_pgsql/pdo_pgsql.c
php5.2-200908130230.mod/ext/pdo_pgsql/pdo_pgsql.c
*** php5.2-200908130230/ext/pdo_pgsql/pdo_pgsql.c 2009-07-18
00:19:00.0 +1200
--- php5.2-200908130230.mod/ext/pdo_pgsql/pdo_pgsql.c 2009-08-13
16:49:02.0 +1200
***
*** 80,87
*/
PHP_MINIT_FUNCTION(pdo_pgsql)
{
- php_pdo_register_driver(pdo_pgsql_driver);
REGISTER_PDO_CLASS_CONST_LONG(PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT,
PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT);
return SUCCESS;
}
/* }}} */
--- 80,87
*/
PHP_MINIT_FUNCTION(pdo_pgsql)
{
REGISTER_PDO_CLASS_CONST_LONG(PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT,
PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT);
+ php_pdo_register_driver(pdo_pgsql_driver);
return SUCCESS;
}
/* }}} */
diff -Nacr php5.2-200908130230/ext/pdo_pgsql/pgsql_driver.c
php5.2-200908130230.mod/ext/pdo_pgsql/pgsql_driver.c
*** php5.2-200908130230/ext/pdo_pgsql/pgsql_driver.c2009-07-18
00:19:00.0 +1200
--- php5.2-200908130230.mod/ext/pdo_pgsql/pgsql_driver.c2009-08-13
16:49:02.0 +1200
***
*** 248,253
--- 248,257
}
}
+ if (H-emulate_prepare == 1) {
+ emulate = 1;
+ }
+
if (!emulate PQprotocolVersion(H-server) 2) {
stmt-supports_placeholders = PDO_PLACEHOLDER_NAMED;
stmt-named_rewrite_template = $%d;
***
*** 646,652
static int pdo_pgsql_set_attr(pdo_dbh_t *dbh, long attr, zval *val
TSRMLS_DC)
{
! return 0;
}
static struct pdo_dbh_methods pgsql_methods = {
--- 650,668
static int pdo_pgsql_set_attr(pdo_dbh_t *dbh, long attr, zval *val
TSRMLS_DC)
{
! switch (attr) {
! convert_to_boolean(val);
!
! case PDO_ATTR_EMULATE_PREPARES:
! ((pdo_pgsql_db_handle
*)dbh-driver_data)-emulate_prepare =
Z_BVAL_P(val);
! return 1;
!
! case PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT:
! ((pdo_pgsql_db_handle
*)dbh-driver_data)-emulate_prepare =
Z_BVAL_P(val);
! return 1;
! default:
! return 0;
! }
}
static struct pdo_dbh_methods pgsql_methods = {
diff -Nacr php5.2-200908130230/ext/pdo_pgsql/php_pdo_pgsql_int.h
php5.2-200908130230.mod/ext/pdo_pgsql/php_pdo_pgsql_int.h
*** php5.2-200908130230/ext/pdo_pgsql/php_pdo_pgsql_int.h 2009-07-18
00:19:00.0 +1200
---
php5.2-200908130230.mod/ext/pdo_pgsql/php_pdo_pgsql_int.h 2009-08-13
16:49:02.0 +1200
***
*** 40,45
--- 40,46
typedef struct {
PGconn *server;
unsignedattached:1;
+ unsignedemulate_prepare:1;
unsigned_reserved:31;
pdo_pgsql_error_infoeinfo;
Oid pgoid;
[2009-08-13 00:54:37] mark dot kirkwood at catalyst dot net dot nz
It seems this could be viewed as part of a larger issue to do with how
the various drivers implement ATTR_EMULATE_PREPARES - e.g there are
differences between PDO::mysql and PDO::pgsql (as discussed in 2nd
paragraph of http://bugs.php.net/bug.php?id=44202), reproduced here as
44202 has been closed:
PDO_MYSQL and PDO_PGSQL use different approaches for enforcing
emulation. PDO_MYSQL uses
#48216 [Opn-Fbk]: PHP Fatal error: SOAP-ERROR: Parsing WSDL: Extra content at the end of the doc
ID: 48216 Updated by: sjo...@php.net Reported By: mark at everytruckjob dot com -Status: Open +Status: Feedback Bug Type: SOAP related Operating System: CentOs 5.3 PHP Version: 5.3.0RC2 New Comment: I tested using the HTTP trace Robert Ripley sent. I discovered some things: Libxml uses the PHP stream wrappers to load the WSDL. These stream wrappers return a malformed WSDL to libxml. This is not specific to SOAP. Running file_get_contents($wsdl) also returns a malformed WSDL. It is reproducible with PHP 5.3 but not with PHP 5.3-HEAD. This suggests that this bug has already been fixed. Previous Comments: [2009-10-06 17:09:14] robert dot ripley at fhchs dot edu I'm also experiencing the same problem. Here is the HTTP header of the WSDL: HTTP/1.1 200 OK\r\n Date: Tue, 06 Oct 2009 16:48:26 GMT\r\n Server: Apache/2.2.8 (Win32) PHP/5.2.5\r\n X-Powered-By: PHP/5.2.5\r\n Expires: Wed, 06 Oct 2010 04:00:00 GMT\r\n Cache-Control: no-store, no-cache, must-revalidate\r\n Pragma: no-cache\r\n Last-Modified: Tue, 06 Oct 2009 16:48:26 GMT\r\n Cache-Control: post-check=0, pre-check=0\r\n Vary: User-Agent\r\n Keep-Alive: timeout=5, max=100\r\n Connection: Keep-Alive\r\n Transfer-Encoding: chunked\r\n Content-Type: application/xml;\r\n \r\n [2009-09-18 16:39:44] boris dot t at usask dot ca it seems that X-Powered-By: is causing problems. The same problem exists when HTTP/1.x 200 OK Date: Fri, 18 Sep 2009 16:24:06 GMT X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0 Content-Type: text/xml;charset=utf-8 Connection: close Transfer-Encoding: chunked and the same code works when HTTP/1.x 200 OK Server: Apache-Coyote/1.1 Content-Type: text/xml;charset=utf-8 Transfer-Encoding: chunked Date: Fri, 18 Sep 2009 16:23:28 GMT [2009-09-07 20:04:53] sjo...@php.net Thank you for your feedback. It would be most helpful to us if you could supply us with the HTTP transaction of the retrieval of the WSDL. You may use a sniffer like Wireshark to obtain this information, or use this script I wrote http://www.gissen.nl/files/sniff.php. [2009-09-07 00:43:35] michael dot tibben at gmail dot com We are experiencing a similar issue. However, the HTTP reply is using chunked transfer encoding (Content-Length is NOT required when using chunked) HTTP/1.1 200 OK Date: Sun, 06 Sep 2009 23:25:16 GMT Server: Apache X-Powered-By: Servlet/2.4 JSP/2.0 Transfer-Encoding: chunked Content-Type: text/xml; charset=UTF-8 [2009-06-24 10:23:47] sjoerd-php at linuxonly dot nl Thank you for your bug report. The WSDL URL you supply does not send a Content-Length or Transfer-Encoding header in some cases, which is mandatory in a response with a body. In other words, it does not follow the HTTP protocol. You should contact the provider of the WSDL about this. GET /url HTTP/1.0 Host: example.com HTTP/1.1 200 OK Date: Wed, 24 Jun 2009 10:18:10 GMT Server: Apache Connection: close Content-Type: text/xml ?xml version=1.0 encoding=UTF-8?... 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/48216 -- Edit this bug report at http://bugs.php.net/?id=48216edit=1
#48216 [Fbk]: PHP Fatal error: SOAP-ERROR: Parsing WSDL: Extra content at the end of the doc
ID: 48216 Updated by: sjo...@php.net Reported By: mark at everytruckjob dot com Status: Feedback Bug Type: SOAP related Operating System: CentOs 5.3 PHP Version: 5.3.0RC2 New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-10-07 18:29:40] sjo...@php.net I tested using the HTTP trace Robert Ripley sent. I discovered some things: Libxml uses the PHP stream wrappers to load the WSDL. These stream wrappers return a malformed WSDL to libxml. This is not specific to SOAP. Running file_get_contents($wsdl) also returns a malformed WSDL. It is reproducible with PHP 5.3 but not with PHP 5.3-HEAD. This suggests that this bug has already been fixed. [2009-10-06 17:09:14] robert dot ripley at fhchs dot edu I'm also experiencing the same problem. Here is the HTTP header of the WSDL: HTTP/1.1 200 OK\r\n Date: Tue, 06 Oct 2009 16:48:26 GMT\r\n Server: Apache/2.2.8 (Win32) PHP/5.2.5\r\n X-Powered-By: PHP/5.2.5\r\n Expires: Wed, 06 Oct 2010 04:00:00 GMT\r\n Cache-Control: no-store, no-cache, must-revalidate\r\n Pragma: no-cache\r\n Last-Modified: Tue, 06 Oct 2009 16:48:26 GMT\r\n Cache-Control: post-check=0, pre-check=0\r\n Vary: User-Agent\r\n Keep-Alive: timeout=5, max=100\r\n Connection: Keep-Alive\r\n Transfer-Encoding: chunked\r\n Content-Type: application/xml;\r\n \r\n [2009-09-18 16:39:44] boris dot t at usask dot ca it seems that X-Powered-By: is causing problems. The same problem exists when HTTP/1.x 200 OK Date: Fri, 18 Sep 2009 16:24:06 GMT X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0 Content-Type: text/xml;charset=utf-8 Connection: close Transfer-Encoding: chunked and the same code works when HTTP/1.x 200 OK Server: Apache-Coyote/1.1 Content-Type: text/xml;charset=utf-8 Transfer-Encoding: chunked Date: Fri, 18 Sep 2009 16:23:28 GMT [2009-09-07 20:04:53] sjo...@php.net Thank you for your feedback. It would be most helpful to us if you could supply us with the HTTP transaction of the retrieval of the WSDL. You may use a sniffer like Wireshark to obtain this information, or use this script I wrote http://www.gissen.nl/files/sniff.php. [2009-09-07 00:43:35] michael dot tibben at gmail dot com We are experiencing a similar issue. However, the HTTP reply is using chunked transfer encoding (Content-Length is NOT required when using chunked) HTTP/1.1 200 OK Date: Sun, 06 Sep 2009 23:25:16 GMT Server: Apache X-Powered-By: Servlet/2.4 JSP/2.0 Transfer-Encoding: chunked Content-Type: text/xml; charset=UTF-8 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/48216 -- Edit this bug report at http://bugs.php.net/?id=48216edit=1
#49226 [Fbk]: SoapServer failing on construction (cannot load wsdl)
ID: 49226
Updated by: sjo...@php.net
Reported By: richard at rjharrison dot org
Status: Feedback
Bug Type: SOAP related
Operating System: linux
PHP Version: 5.3.0
New Comment:
See also Bug #48216 PHP Fatal error: SOAP-ERROR: Parsing WSDL: Extra
content at the end of the doc
Previous Comments:
[2009-10-07 16:28:23] petro at eps1lon dot com
That should be 5.3.1RC1.
[2009-10-07 16:25:01] petro at eps1lon dot com
I was having the same problem with SoapClient under 5.3.0. It is
working fine under 5.3.RC1.
[2009-10-01 11:37:09] sjo...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-09-30 18:26:54] sjo...@php.net
Evrard mailed me a HTTP trace, which I put here:
http://pastebin.com/f25b554f9
I could reproduce this with PHP 5.3, not PHP 5.3-HEAD, so this may have
already been fixed in trunk.
[2009-09-23 09:13:56] evrard at h2a dot lu
For everybody that are looking for a little fix for that, force
SoapClient to send an HTTP 1.0 request and your script may run again. It
is working for me with PHP 5.3.0, ZEND 1.9 (minimal package, via PEAR)
and APACHE 2.2.12 on Windows XP.
?php
try
{
$context = stream_context_create( array(
'http' = array(
'protocol_version'= '1.0' ,
'header'= 'Content-Type: text/xml;' ,
),
) );
$options = array(
'stream_context' = $context ,
);
$client = new SoapClient( 'http://myserver/path?wsdl' , $options
);
}
catch( Exception $e )
{
// You should not be here anymore
}
?
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/49226
--
Edit this bug report at http://bugs.php.net/?id=49226edit=1
#49804 [Bgs]: cannot use [...] after a function returning array
ID: 49804 User updated by: valerio dot giuffrida88 at gmail dot com Reported By: valerio dot giuffrida88 at gmail dot com Status: Bogus Bug Type: Compile Failure Operating System: ubuntu PHP Version: 5.2SVN-2009-10-07 (snap) New Comment: why not? Other languanges like C/C++ or java allows that Previous Comments: [2009-10-07 17:22:43] der...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . [2009-10-07 17:11:50] valerio dot giuffrida88 at gmail dot com Description: If i want to get an element of an array directly returned by a function, using [], it will prints Parse error: syntax error, unexpected '[', expecting ',' or ';' in php shell code on line 1 Reproduce code: --- $a = array(a,b,c); echo array_values($a)[0]; //it (doesnt) works with any function that retuns an array Expected result: print to screen something like that: a Actual result: -- Parse error: syntax error, unexpected '[', expecting ',' or ';' in php shell code on line 1 -- Edit this bug report at http://bugs.php.net/?id=49804edit=1
#49806 [NEW]: proc_nice() for Windows
From: ka...@php.net Operating system: Windows PHP version: 6SVN-2009-10-07 (SVN) PHP Bug Type: Feature/Change Request Bug description: proc_nice() for Windows Description: As discussed with Pierre and sent to the internals-win ML, then here is a patch for enabling proc_nice() under Windows. This patch is abit modified from the version sent to the ML and is added into TSRM like popen. Patch is made for trunk: http://pastie.org/645963 -- Edit bug report at http://bugs.php.net/?id=49806edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49806r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49806r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49806r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49806r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49806r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49806r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49806r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49806r=needscript Try newer version: http://bugs.php.net/fix.php?id=49806r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49806r=support Expected behavior: http://bugs.php.net/fix.php?id=49806r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49806r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49806r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49806r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49806r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49806r=dst IIS Stability: http://bugs.php.net/fix.php?id=49806r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49806r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49806r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49806r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49806r=mysqlcfg
#49806 [Opn-Asn]: proc_nice() for Windows
ID: 49806 Updated by: ka...@php.net Reported By: ka...@php.net -Status: Open +Status: Assigned Bug Type: Feature/Change Request Operating System: Windows PHP Version: 6SVN-2009-10-07 (SVN) -Assigned To: +Assigned To: kalle Previous Comments: [2009-10-07 20:20:54] ka...@php.net Description: As discussed with Pierre and sent to the internals-win ML, then here is a patch for enabling proc_nice() under Windows. This patch is abit modified from the version sent to the ML and is added into TSRM like popen. Patch is made for trunk: http://pastie.org/645963 -- Edit this bug report at http://bugs.php.net/?id=49806edit=1
#49344 [Com]: pdo_mssql fails to connect,throws PDOException SQLSTATE[] (null) (severity 0)
ID: 49344
Comment by: philipp at servicemail24 dot de
Reported By: rockyjl at gmai dot com
Status: No Feedback
Bug Type: PDO related
Operating System: win2003 X64
PHP Version: 5.2.11RC1
Assigned To: felipe
New Comment:
The same error occurs using Ubuntu 0910 with Zend Framework:
require_once('Zend/Db.php');
$db = Zend_Db::factory('Pdo_Mssql', array(
'host' = 'sqlsrv',
'username' = 'php',
'password' = 'secret',
'dbname' = 'myDatabase',
'pdoType' = 'dblib'
));
$result = $db-fetchAll(SELECT * FROM MyTable);
var_dump($result);
Zend_Db_Adapter_Exception: SQLSTATE[] (null) (severity 0) in
/usr/share/php/libzend-framework-php/Zend/Db/Adapter/Pdo/Abstract.php on
line 144
Previous Comments:
[2009-09-23 04:20:01] Rockyjl at gmail dot com
My Modification:
static int pdo_dblib_handle_factory(pdo_dbh_t *dbh, zval
*driver_options TSRMLS_DC)
{
pdo_dblib_db_handle *H;
int i, ret = 0;
char *location = L=;
struct pdo_data_src_parser vars[] = {
{ charset,NULL, 0 },
{ appname,PHP PDO_DBLIB_FLAVOUR, 0 },
{ host, 127.0.0.1, 0 },
{ dbname, NULL, 0 },
{ secure, NULL, 0 }, /* DBSETLSECURE */
/* TODO: DBSETLVERSION ? */
};
php_pdo_parse_data_source(dbh-data_source, dbh-data_source_len,
vars, 5);
H = pecalloc(1, sizeof(*H), dbh-is_persistent);
H-login = dblogin();
H-err.sqlstate = dbh-error_code;
if (!H-login) {
strcat(location, login);
goto cleanup;
}
if (dbh-username) {
DBSETLUSER(H-login, dbh-username);
}
if (dbh-password) {
DBSETLPWD(H-login, dbh-password);
}
#if !PHP_DBLIB_IS_MSSQL
if (vars[0].optval) {
DBSETLCHARSET(H-login, vars[0].optval);
}
#endif
DBSETLAPP(H-login, vars[1].optval);
#if PHP_DBLIB_IS_MSSQL
dbprocerrhandle(H-login, (EHANDLEFUNC) error_handler);
dbprocmsghandle(H-login, (MHANDLEFUNC) msg_handler);
#endif
H-link = dbopen(H-login, vars[2].optval);
if (H-link == NULL) {
strcat(location, link);
goto cleanup;
}
/* dblib do not return more than this length from text/image */
DBSETOPT(H-link, DBTEXTLIMIT, 2147483647);
/* limit text/image from network */
DBSETOPT(H-link, DBTEXTSIZE, 2147483647);
if (vars[3].optval FAIL == dbuse(H-link, vars[3].optval)) {
strcat(location, optval);
goto cleanup;
}
ret = 1;
dbh-max_escaped_char_length = 2;
dbh-alloc_own_columns = 1;
cleanup:
for (i = 0; i sizeof(vars)/sizeof(vars[0]); i++) {
if (vars[i].freeme) {
efree(vars[i].optval);
}
}
dbh-methods = dblib_methods;
dbh-driver_data = H;
if (!ret) {
zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
SQLSTATE[%s] %s (severity %d) %s, //I want to
findout the bug
location !
DBLIB_G(err).sqlstate,
DBLIB_G(err).dberrstr,
DBLIB_G(err).severity,
location);
}
return ret;
}
The PDO MSSQL work is correct, the bug never happen and never throws
any PDOException after Complie php_pdo_mssql.dll ...
I think my modification STOP all PDOException throw ...
Anyone can tell me what is the problem ?
[2009-09-17 01:00:02] 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-09-10 15:38:07] Rockyjl at gmail dot com
apache 2.2.13 + PHP 5.2 (5.2.11RC3-dev) VC6 x86 Thread Safe
(2009-Sep-10 12:00:00)
often happen error:
[2009-09-10 23:30:10]
127.0.0.1
ApacheBench/2.3
SQLSTATE[] (null) (severity 0)
This patch cannot work ???!!!
[2009-09-10 06:07:50] Rockyjl at gmail dot com
PHP 5.3 (5.3.2-dev) VC6 x86 Thread Safe (2009-Sep-10 06:00:00)
http://windows.php.net/downloads/snaps/php-5.3-win32-VC6-x86-latest.zip
the bug happen too
[2009-09-10 01:20:42] s...@php.net
Automatic comment from SVN
#48764 [Opn-Fbk]: PDO_pgsql::query always uses implicit prepared statements if v3 proto available
ID: 48764
Updated by: mbecc...@php.net
Reported By: mark dot kirkwood at catalyst dot net dot nz
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Linux 2.6.28 (Ubuntu) amd64
PHP Version: 5.3CVS-2009-07-01 (snap)
Assigned To: mbeccati
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-10-07 17:40:17] s...@php.net
Automatic comment from SVN on behalf of mbeccati
Revision: http://svn.php.net/viewvc/?view=revisionrevision=289287
Log: - Fixed bug #48764 (PDO_pgsql::query always uses implicit prepared
statements if v3 proto available)
# original patch by Mark Kirkwood
[2009-08-13 05:22:17] mark dot kirkwood at catalyst dot net dot nz
new patch that handles PDO::ATTR_EMULATE_PREPARES as well
diff -Nacr php5.2-200908130230/ext/pdo_pgsql/pdo_pgsql.c
php5.2-200908130230.mod/ext/pdo_pgsql/pdo_pgsql.c
*** php5.2-200908130230/ext/pdo_pgsql/pdo_pgsql.c 2009-07-18
00:19:00.0 +1200
--- php5.2-200908130230.mod/ext/pdo_pgsql/pdo_pgsql.c 2009-08-13
16:49:02.0 +1200
***
*** 80,87
*/
PHP_MINIT_FUNCTION(pdo_pgsql)
{
- php_pdo_register_driver(pdo_pgsql_driver);
REGISTER_PDO_CLASS_CONST_LONG(PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT,
PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT);
return SUCCESS;
}
/* }}} */
--- 80,87
*/
PHP_MINIT_FUNCTION(pdo_pgsql)
{
REGISTER_PDO_CLASS_CONST_LONG(PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT,
PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT);
+ php_pdo_register_driver(pdo_pgsql_driver);
return SUCCESS;
}
/* }}} */
diff -Nacr php5.2-200908130230/ext/pdo_pgsql/pgsql_driver.c
php5.2-200908130230.mod/ext/pdo_pgsql/pgsql_driver.c
*** php5.2-200908130230/ext/pdo_pgsql/pgsql_driver.c2009-07-18
00:19:00.0 +1200
--- php5.2-200908130230.mod/ext/pdo_pgsql/pgsql_driver.c2009-08-13
16:49:02.0 +1200
***
*** 248,253
--- 248,257
}
}
+ if (H-emulate_prepare == 1) {
+ emulate = 1;
+ }
+
if (!emulate PQprotocolVersion(H-server) 2) {
stmt-supports_placeholders = PDO_PLACEHOLDER_NAMED;
stmt-named_rewrite_template = $%d;
***
*** 646,652
static int pdo_pgsql_set_attr(pdo_dbh_t *dbh, long attr, zval *val
TSRMLS_DC)
{
! return 0;
}
static struct pdo_dbh_methods pgsql_methods = {
--- 650,668
static int pdo_pgsql_set_attr(pdo_dbh_t *dbh, long attr, zval *val
TSRMLS_DC)
{
! switch (attr) {
! convert_to_boolean(val);
!
! case PDO_ATTR_EMULATE_PREPARES:
! ((pdo_pgsql_db_handle
*)dbh-driver_data)-emulate_prepare =
Z_BVAL_P(val);
! return 1;
!
! case PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT:
! ((pdo_pgsql_db_handle
*)dbh-driver_data)-emulate_prepare =
Z_BVAL_P(val);
! return 1;
! default:
! return 0;
! }
}
static struct pdo_dbh_methods pgsql_methods = {
diff -Nacr php5.2-200908130230/ext/pdo_pgsql/php_pdo_pgsql_int.h
php5.2-200908130230.mod/ext/pdo_pgsql/php_pdo_pgsql_int.h
*** php5.2-200908130230/ext/pdo_pgsql/php_pdo_pgsql_int.h 2009-07-18
00:19:00.0 +1200
---
php5.2-200908130230.mod/ext/pdo_pgsql/php_pdo_pgsql_int.h 2009-08-13
16:49:02.0 +1200
***
*** 40,45
--- 40,46
typedef struct {
PGconn *server;
unsignedattached:1;
+ unsignedemulate_prepare:1;
unsigned_reserved:31;
pdo_pgsql_error_infoeinfo;
Oid pgoid;
[2009-08-13 00:54:37] mark dot kirkwood at catalyst dot net dot nz
It seems this could be viewed as part of a larger issue to do with how
the various drivers implement ATTR_EMULATE_PREPARES - e.g there are
differences between PDO::mysql and PDO::pgsql (as discussed in 2nd
paragraph of http://bugs.php.net/bug.php?id=44202), reproduced here as
44202 has been closed:
PDO_MYSQL and PDO_PGSQL use different approaches for enforcing
emulation. PDO_MYSQL uses $pdo-setAttribute(PDO::ATTR_EMULATE_PREPARES,
...) and PDO_PGSQL requires you to use $pdo-prepare(...,
array(PDO::ATTR_EMULATE_PREPARES
= ...)). So, one uses setAttribute() and the other uses prepare(). As
PDO is aimed to be a database access layer abstraction, I wonder if this
could be unified.
[2009-07-02
#48190 [Ver]: Content-type parameter boundary is not case-insensitive in HTTP uploads
ID: 48190 Updated by: garre...@php.net Reported By: carsten_sttgt at gmx dot de Status: Verified Bug Type: HTTP related Operating System: Windows NT PHP Version: 5.*CVS, 6CVS (2009-05-08) -Assigned To: +Assigned To: garretts New Comment: I'm testing a fix I've built for this right now. Previous Comments: [2009-10-07 02:04:34] ba dot mariam92 at yahoo dot com i don't now the answer f that up [2009-05-09 04:08:27] j...@php.net Yes, I know it's not an upload per se, but the code that handles is one that most of the time takes care of file uploads. :) Problem is in rfc1867.c:804, strstr() should be replaced with something that does the same but case-insensitively. [2009-05-08 23:23:57] carsten_sttgt at gmx dot de Just curious, but what client actually uses uppercase/mixed case boundary parameter name? I'm using imap_mail_compose() to build the 'header' and 'content' keys in the stream_context_create() options array. And then using this context with e.g. file_get_contents() to make the POST request. BTW: The above example is a HTTP POST request without a file upload. [2009-05-08 22:05:58] j...@php.net Just curious, but what client actually uses uppercase/mixed case boundary parameter name? (and [2009-05-08 21:41:55] carsten_sttgt at gmx dot de In my first post I have refereed to RFC2045, but RFC2616 is also very clear about this [1]: | The type, subtype, and parameter attribute names are | case- insensitive. Parameter values might or might | not be case-sensitive, depending on the semantics | of the parameter name. type = MULTIPART subtype = form-data parameter attribute name = BOUNDARY parameter value = 250-16659-1241787336=:9320 [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7 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/48190 -- Edit this bug report at http://bugs.php.net/?id=48190edit=1
#47999 [Opn-Bgs]: tempnam() fails to create file
ID: 47999
Updated by: garre...@php.net
Reported By: phpbug at danf dot oib dot com
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.2.9
-Assigned To:
+Assigned To: garretts
New Comment:
I'm unable to reproduce this with PHP 5.2.9-2 and PHP 5.3.
I used your repro code, and tried:
the command line:
Successfully created
C:\Users\garretts\AppData\Local\Temp\ran81CC.tmp.
from a web page:
Successfully created C:\Windows\Temp\ranBFA6.tmp.
Previous Comments:
[2009-04-17 16:41:22] phpbug at danf dot oib dot com
Yes, D:\temp has Modify permission for Everyone. Remember, this worked
in PHP 5.2.3 on the same server, so it can't be a permissions issue,
assuming the method the tempnam() function uses to determine which
directory to use was consistent from 5.2.3 forward.
[2009-04-17 10:45:00] j...@php.net
Check the permissions on the temporary files path (TEMP / TMP, or
whatever it is set to in your system) or pass a path that is writable.
[2009-04-17 03:34:46] phpbug at danf dot oib dot com
Description:
tempnam() does not create a temporary file, and silently fails. This
worked fine in PHP 5.2.3, but starting failing in 5.2.6 (or somewhere in
between). It still does not work in 5.2.8 or 5.2.9-1.
I've tested with both the IIS module (php5isapi.dll) and php-cgi.exe,
with the same results.
open_basedir is off.
Reproduce code:
---
?php
$tempnam = tempnam('','random') or die(Can't create tmpfile.\n);
echo Successfully created $tempnam.\n;
?
Expected result:
Successfully created D:\temp\ran1E42.tmp.
Actual result:
--
Can't create tmpfile.
--
Edit this bug report at http://bugs.php.net/?id=47999edit=1
#42608 [Com]: Example #660 (filter_input_array) is wrong
ID: 42608 Comment by: ChadFulton at gmail dot com Reported By: phpbugs dot 20 dot zsh at spamgourmet dot com Status: Open Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 5.2.4 New Comment: Although this is a very old bug, it seems to me that the poster is incorrect; I suspect the problem is that the poster attempted to set the $_POST array during runtime (e.g. $_POST = array( ... ); ), and filter_input_array does not allow runtime modification $_POST, $_GET, etc. Previous Comments: [2007-09-10 11:04:44] phpbugs dot 20 dot zsh at spamgourmet dot com Description: The example will not output the array shown below the example code -- any undefined variable will cause filter_input_array() to return (so the output would be NULL). You'll notice I've classified this as a change request rather than a documentation problem, for the expected (and described (Return Values)) behavior in example #660 makes WAY more sense. Reproduce code: --- http://www.php.net/filter_input_array -- Edit this bug report at http://bugs.php.net/?id=42608edit=1
