[PHP-BUG] Bug #54987 [NEW]: rmdir() does not clear statcache
From: Operating system: Windows 7 Pro 32-bit PHP version: 5.3.6 Package: Directory function related Bug Type: Bug Bug description:rmdir() does not clear statcache Description: See bug 43137. The same bug applies to Windows. Given a directory structure C:\Test\Test2 with no files in either directory, rmdir(C:\Test\Test2) succeeds but subsequent rmdir(C:\Test) fails with directory not empty, even though it is empty. Running clearstatcache() prior to rmdir(C:\Test) works around the problem. Test script: --- if (file_exists(C:\Test\Test2)) rmdir(C:\Test\Test2); rmdir(C:\Test) Expected result: c:\Test\Test2 is deleted C:\Test is deleted No warnings Actual result: -- C:\Test\Test2 is deleted C:\Test is NOT deleted Receive warning that C:\Test is not empty -- Edit bug report at http://bugs.php.net/bug.php?id=54987edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54987r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54987r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54987r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54987r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54987r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54987r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54987r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54987r=needscript Try newer version: http://bugs.php.net/fix.php?id=54987r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54987r=support Expected behavior: http://bugs.php.net/fix.php?id=54987r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54987r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54987r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54987r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54987r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54987r=dst IIS Stability: http://bugs.php.net/fix.php?id=54987r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54987r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54987r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54987r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54987r=mysqlcfg
Bug #49521 [Csd-ReO]: PDO fetchObject sets values before calling constructor
Edit report at http://bugs.php.net/bug.php?id=49521edit=1 ID: 49521 Updated by: da...@php.net Reported by: waps at pisem dot net Summary: PDO fetchObject sets values before calling constructor -Status: Closed +Status: Re-Opened Type: Bug Package: PDO related Operating System: Ubuntu 8.10 x64 PHP Version: 5.2.10 Assigned To: pierrick New Comment: According to the ML [1], Johannes, Felipe and Derick all agreed that this fix should be reverted, and instead the current behavior (values then constructor) should be properly documented. The desired behavior can be accomplished using the PDO::FETCH_PROPS_LATE option since 5.2.0. This means commit #290786 must be reverted in 5_2. It was already reverted in 5_3. (Commit #294903 [2]) [1] http://marc.info/?l=php-internalsm=126451457205904w=2 [2] http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/pdo/pdo_stmt.c? r1=293036r2=294903 Previous Comments: [2010-02-12 00:19:11] s...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revisionrevision=294942 Log: merge 290786: Revert 290786: Fixed bug #49521 (PDO fetchObject sets values before calling constructor) [2010-02-11 22:14:06] s...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revisionrevision=294903 Log: Revert 290786: Fixed bug #49521 (PDO fetchObject sets values before calling constructor) [2009-11-15 16:23:41] fel...@php.net 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. Thanks for the patch. [2009-11-15 16:20:37] s...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionrevision=290786 Log: - Fixed bug #49521 (PDO fetchObject sets values before calling constructor) (patch by Pierrick) [2009-11-12 05:00:55] pierr...@php.net Patch available at: http://www.adoy.net/php/49521.PHP_5_2.patch http://www.adoy.net/php/49521.PHP_5_3.patch http://www.adoy.net/php/49521.PHP_6_0.patch 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=49521 -- Edit this bug report at http://bugs.php.net/bug.php?id=49521edit=1
#161 [Csd]: ReadFile File do not honour SAFE-MODE
ID: 161 Updated by: [EMAIL PROTECTED] Reported By: benkovsk at pha dot pvt dot cz Status: Closed -Bug Type: Other +Bug Type: *General Issues Operating System: Digital Unix v3.2D2 PHP Version: 3.0b5 Assigned To: rasmus New Comment: . Previous Comments: [1998-03-15 22:02:17] rasmus Fixed. Patch is available at: http://ca.php.net/cvsweb.cgi/fopen-wrappers.c?r1=1.14r2=1.15 [1998-03-11 08:50:16] benkovsk at pha dot pvt dot cz Hi, I can read root owned files (/etc/passwd) with ReadFile() or File() even if phtml file and dir is owned by non-root user. phpinfo reports safemode=1. Include() in the same script on the same file returns permission error, which is right. BTW: Why there's not a Bug type 'Security'? My config line: ./configure --with-apache=../apache_1.3b5 --with-config-file-path=/usr/internet/apache/conf --disable-debug --enable -safe-mode --with-exec-dir=/usr/internet/apache/safe-bin --enable-memory-limit -- Edit this bug report at http://bugs.php.net/?id=161edit=1
#33621 [Asn]: Exit code 0377 when calling a non-existant method using a dynamic call
ID: 33621
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
-Bug Type: Scripting Engine problem
+Bug Type: Reproducible crash
Operating System: Ubuntu Linux 5.04
PHP Version: 5CVS-2005-07-09 (dev)
Assigned To: dmitry
New Comment:
After further testing, I have found two more cases where this error
occurs:
When __call is defined, but no args are specified (i.e. function
__call() { }) and is_callable() or method_exists() are called, Exit
Code 0377 is also given.
Whilst I understand this is an erroneous situation, it should either
not care (i.e. func_get_args is being used for some stupid reason) or
throw an error.
- Davey
Previous Comments:
[2005-07-09 05:17:59] [EMAIL PROTECTED]
Description:
I'm using head as of 5 minutes ago, approx: 23:10 EST
Calling a non-existant method using the $obj-{$var}() notation causes
an unexplained exit of the script with the exit code 0377.
Reproduce code:
---
?php
class foo {
function __construct()
{
$var = foo;
$this-{$var}();
}
}
$foo = new foo;
?
Expected result:
Nothing
Actual result:
--
With --enable-debug all I get this from gdb:
(gdb) run -f
/var/www/php-cvs/testcase/evil_death_variable_method_call_nonexistant.php
Starting program: /var/www/php-cvs/php-src/sapi/cli/php -f
/var/www/php-cvs/testcase/evil_death_variable_method_call_nonexistant.php
[Thread debugging using libthread_db enabled]
[New Thread -1214975328 (LWP 9095)]
Program exited with code 0377.
--
Edit this bug report at http://bugs.php.net/?id=33621edit=1
#29394 [Opn-Bgs]: Cant delete folder with name 2003
ID: 29394 Updated by: [EMAIL PROTECTED] Reported By: m at shnee dot com -Status: Open +Status: Bogus Bug Type: Directory function related Operating System: winxp pro PHP Version: 4.3.7 New Comment: Tested in WinXP Home SP2, both functions work fine for me. - Davey Previous Comments: [2004-07-26 21:03:16] m at shnee dot com Description: Its funny, when a directory is named 2003, I am unable to rmdir or rename it. If I change the folder name (using windows explorer) to 2005, then I can run rmdir and rename with no problem. The return error is Permission Denied. But that isnt the issue as I can create a 2003 folder and 2005 folder at the same time, and I get the same problem. I can only edit/delete 2005, and 2003 always gives permission denied no matter what. I realize its possible this could be a windows issue. Just curious don't ya think? Reproduce code: --- rmdir(2003); rename (2003, 2002); Expected result: I expect it to delete/rename the directory. Actual result: -- Warning: rmdir(2003): Permission denied in C:\Documents and Settings\Mark\Desktop\www\new_pics\index.php on line 401 -- Edit this bug report at http://bugs.php.net/?id=29394edit=1
#27709 [Bgs-Opn]: SimpleXML xpath function doesn't like default namespaces
ID: 27709
Updated by: [EMAIL PROTECTED]
Reported By: fjortiz at comunet dot es
-Status: Bogus
+Status: Open
Bug Type: SimpleXML related
-Operating System: Windows 2000 Server
+Operating System: Irrelevant
-PHP Version: 5.0.0RC1
+PHP Version: 5.0RC3-dev
-Assigned To:
+Assigned To: rrichards
New Comment:
This *is* a bug, SimpleXML does not provide a registerNamespace()
method like the DOM XPath implementation does. Without this, the XPath
implementation in SimpleXML is crippled.
So its half a bug, and half a feature request. This *needs* to be added
before 5.0 final IMO
The only way I can get this to workright now is:
$xml =EOF
?xml version=1.0 ?
xml xmlns=http://bar;
child attribute=value1
morechildren /
morechildren /
morechildren /
morechildren /
/child
/xml
EOF;
$simple_xml = simplexml_load_string($xml);
// Add a namespace with the same URI as the default
$simple_xml['xmlns:bar'] = http://bar;;
// Reload the XML so the namespace is recognised
$simple_xml = simplexml_load_string($simple_xml-asXML());
- Davey
Previous Comments:
[2004-03-26 08:09:55] [EMAIL PROTECTED]
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
This is an XPath limitation.
You need to use an expression like //*[local-name() = 'a'] or dont use
default namespaces.
[2004-03-26 04:51:30] fjortiz at comunet dot es
Description:
Hi,
this example works with SimpleXML xpath:
$string = XML
?xml version=1.0 encoding =UTF-8 ?
a xmlns:ns=urn:1
b
ctext/c
cstuff/c
/b
d
ccode/c
/d
/a
XML;
$xml = simplexml_load_string($string);
$res = $xml-xpath('//a'); // returns array(1)
But if we don't use a namespace prefix (default namespace), xpath,
returns an empty array, array(0), for any xpath search:
$string = XML
?xml version=1.0 encoding =UTF-8 ?
a xmlns=urn:1
b
ctext/c
cstuff/c
/b
d
ccode/c
/d
/a
XML;
$xml = simplexml_load_string($string);
$res = $xml-xpath('//a'); // returns array(0)
This is a simple example, I found the problem with a bigger XML file (a
WSDL file). This WSDL has 5 namespaces defined, and no problem at all
with SimpleXML, as long as you don't define a default namespace...
Thanks for your attention
--
Edit this bug report at http://bugs.php.net/?id=27709edit=1
#26662 [Ver]: Inconsistency in variable setting allows variables that start with numbers
ID: 26662
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 4CVS-2003-12-18 (stable)
New Comment:
Verified on PHP5b2, FreeBSD 4.4.
PHP4 Snapshot on FreeBSD 4.4 yields this:
[EMAIL PROTECTED]:~/php4-STABLE-200312190030/sapi/cli]$ ./php -r '${1} =
foo; echo ${1}, \n;'
Segmentation fault (core dumped)
Running the script on Win32 PHP4 snapshot (same one) gives an
Application Error.
Previous Comments:
[2003-12-18 21:25:21] [EMAIL PROTECTED]
Confirmed this bug is in PHP 5 B3RC1 as well. It gets worse, you can
put whatever you want in ${} and it'll take it just fine...
[2003-12-18 21:06:52] [EMAIL PROTECTED]
Description:
It is possible to set variables that start with numbers.
I reproduced this with a PHP 4.3.x-dev snapshot AND PHP 5.0.0b2 (I was
unable to get a snap to compile. autoconf errors out the wazoo).
Reproduce code:
---
[EMAIL PROTECTED] cli $ ./php -r '${1} = foo; echo ${1}, \n;'
foo
Expected result:
A parse error
Actual result:
--
Outputs 'foo'
--
Edit this bug report at http://bugs.php.net/?id=26662edit=1
#26662 [Opn]: Inconsistency in variable setting allows variables that start with numbers
ID: 26662
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 4CVS-2003-12-18 (stable)
New Comment:
Both the FBSD and Win32 crashes are attributeable to the xdebug
extension. Am filing a bug with the author on those. Please disregard
those issues here.
- Davey
Previous Comments:
[2003-12-18 21:51:46] [EMAIL PROTECTED]
This is not a dup, as it is not fixed in PHP 5. Re-opening.
[2003-12-18 21:42:28] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Dupe of bug #26601 which is marked won't fix.
[2003-12-18 21:29:16] [EMAIL PROTECTED]
Verified on PHP5b2, FreeBSD 4.4.
PHP4 Snapshot on FreeBSD 4.4 yields this:
[EMAIL PROTECTED]:~/php4-STABLE-200312190030/sapi/cli]$ ./php -r '${1} =
foo; echo ${1}, \n;'
Segmentation fault (core dumped)
Running the script on Win32 PHP4 snapshot (same one) gives an
Application Error.
[2003-12-18 21:25:21] [EMAIL PROTECTED]
Confirmed this bug is in PHP 5 B3RC1 as well. It gets worse, you can
put whatever you want in ${} and it'll take it just fine...
[2003-12-18 21:06:52] [EMAIL PROTECTED]
Description:
It is possible to set variables that start with numbers.
I reproduced this with a PHP 4.3.x-dev snapshot AND PHP 5.0.0b2 (I was
unable to get a snap to compile. autoconf errors out the wazoo).
Reproduce code:
---
[EMAIL PROTECTED] cli $ ./php -r '${1} = foo; echo ${1}, \n;'
foo
Expected result:
A parse error
Actual result:
--
Outputs 'foo'
--
Edit this bug report at http://bugs.php.net/?id=26662edit=1
#25676 [Bgs-Opn]: Form hidden input ouput when any form=* is in url_rewriter.tags
ID: 25676
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Session related
Operating System: WinXP/FreeBSD
PHP Version: 4CVS-2003-09-26 (stable)
Previous Comments:
[2003-09-27 08:36:22] [EMAIL PROTECTED]
RTFM Note: If you want XHTML conformity, remove the form entry and
use the fieldset tags around your form fields.
[2003-09-26 23:20:55] [EMAIL PROTECTED]
Description:
Despite there being no form=fakeentry or form= (as I understand it,
providing no value is the same as giving fakeentry) in
url_rewriter.tags the form hidden element for the PHPSESSID is still
output.
I am trying to use form=action as the url_rewriter.tags and whilst this
IS rewritten correctly, the hidden element is still being inserted. It
seems that the fallback mechanism is faulty.
This has been tested on several builds:
PHP 4.3.3RC4 WinXP
Latest Snapshot (200309270130) WinXP
PHP 4.3.3 FreeBSD
Latest Snapshot (200309270130) FreeBSD
I have also had someone reporting the CORRECT behaviour on Debian with
latest CVS so its quite the puzzle...
- Davey
Reproduce code:
---
?php
session_start();
setcookie('PHPSESSID','',0); /* needed if session.use_cookies is still
on */
?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titleUntitled/title
/head
body
?php
ini_set('url_rewriter.tags','a=href,area=href,frame=src,input=src,form=action,foo=bar');
echo ini_get(url_rewriter.tags) . br /;
if(isset($_GET)) {
var_dump($_GET);
}
?
form action=?php echo $_SERVER['PHP_SELF']; ? method=get
p
Foo: input type=text name=foo value= /
br /
Bar: input type=text name=bar value= /
br /
input type=submit value=Test! /
/p
foo href=foo.php bar=null /
/form
/body
/html
Expected result:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titleUntitled/title
/head
body
a=href,area=href,frame=src,input=src,form=action,foo=barbr
/array(0) {
}
form
action=/test/url_rewrite_form_action.php?PHPSESSID=6a5b43d2aef8e2e3158e44fbd3df5d9d
method=getinput type=hidden name=PHPSESSID
value=6a5b43d2aef8e2e3158e44fbd3df5d9d /
p
Foo: input type=text name=foo value= /
br /
Bar: input type=text name=bar value= /
br /
input type=submit value=Test! /
/p
foo href=foo.php
bar=null?PHPSESSID=6a5b43d2aef8e2e3158e44fbd3df5d9d /
/form
/body
/html
Actual result:
--
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titleUntitled/title
/head
body
a=href,area=href,frame=src,input=src,form=action,foo=barbr
/array(0) {
}
form
action=/test/url_rewrite_form_action.php?PHPSESSID=6a5b43d2aef8e2e3158e44fbd3df5d9d
method=getinput type=hidden name=PHPSESSID
value=6a5b43d2aef8e2e3158e44fbd3df5d9d /
p
Foo: input type=text name=foo value= /
br /
Bar: input type=text name=bar value= /
br /
input type=submit value=Test! /
/p
foo href=foo.php
bar=null?PHPSESSID=6a5b43d2aef8e2e3158e44fbd3df5d9d /
/form
/body
/html
--
Edit this bug report at http://bugs.php.net/?id=25676edit=1
#25676 [Opn]: Form hidden input ouput when any form=* is in url_rewriter.tags
ID: 25676
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: WinXP/FreeBSD
PHP Version: 4CVS-2003-09-26 (stable)
New Comment:
I've now had it confirmed on *two* Debian Linux boxes with a 20030927
snapshot that the hidden element does NOT get output.
Trying to confirm on other distros, versions of windows and newer FBSD
versions now.
Note: the Expected Result has the extraneous hidden input, please
mentally remove that ;)
- Davey
Previous Comments:
[2003-09-27 08:36:22] [EMAIL PROTECTED]
RTFM Note: If you want XHTML conformity, remove the form entry and
use the fieldset tags around your form fields.
[2003-09-26 23:20:55] [EMAIL PROTECTED]
Description:
Despite there being no form=fakeentry or form= (as I understand it,
providing no value is the same as giving fakeentry) in
url_rewriter.tags the form hidden element for the PHPSESSID is still
output.
I am trying to use form=action as the url_rewriter.tags and whilst this
IS rewritten correctly, the hidden element is still being inserted. It
seems that the fallback mechanism is faulty.
This has been tested on several builds:
PHP 4.3.3RC4 WinXP
Latest Snapshot (200309270130) WinXP
PHP 4.3.3 FreeBSD
Latest Snapshot (200309270130) FreeBSD
I have also had someone reporting the CORRECT behaviour on Debian with
latest CVS so its quite the puzzle...
- Davey
Reproduce code:
---
?php
session_start();
setcookie('PHPSESSID','',0); /* needed if session.use_cookies is still
on */
?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titleUntitled/title
/head
body
?php
ini_set('url_rewriter.tags','a=href,area=href,frame=src,input=src,form=action,foo=bar');
echo ini_get(url_rewriter.tags) . br /;
if(isset($_GET)) {
var_dump($_GET);
}
?
form action=?php echo $_SERVER['PHP_SELF']; ? method=get
p
Foo: input type=text name=foo value= /
br /
Bar: input type=text name=bar value= /
br /
input type=submit value=Test! /
/p
foo href=foo.php bar=null /
/form
/body
/html
Expected result:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titleUntitled/title
/head
body
a=href,area=href,frame=src,input=src,form=action,foo=barbr
/array(0) {
}
form
action=/test/url_rewrite_form_action.php?PHPSESSID=6a5b43d2aef8e2e3158e44fbd3df5d9d
method=getinput type=hidden name=PHPSESSID
value=6a5b43d2aef8e2e3158e44fbd3df5d9d /
p
Foo: input type=text name=foo value= /
br /
Bar: input type=text name=bar value= /
br /
input type=submit value=Test! /
/p
foo href=foo.php
bar=null?PHPSESSID=6a5b43d2aef8e2e3158e44fbd3df5d9d /
/form
/body
/html
Actual result:
--
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titleUntitled/title
/head
body
a=href,area=href,frame=src,input=src,form=action,foo=barbr
/array(0) {
}
form
action=/test/url_rewrite_form_action.php?PHPSESSID=6a5b43d2aef8e2e3158e44fbd3df5d9d
method=getinput type=hidden name=PHPSESSID
value=6a5b43d2aef8e2e3158e44fbd3df5d9d /
p
Foo: input type=text name=foo value= /
br /
Bar: input type=text name=bar value= /
br /
input type=submit value=Test! /
/p
foo href=foo.php
bar=null?PHPSESSID=6a5b43d2aef8e2e3158e44fbd3df5d9d /
/form
/body
/html
--
Edit this bug report at http://bugs.php.net/?id=25676edit=1
#25676 [Opn]: Form hidden input ouput when any form=* is in url_rewriter.tags
ID: 25676
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: WinXP/FreeBSD
PHP Version: 4CVS-2003-09-26 (stable)
New Comment:
I can also confirm no hidden input element is output on Gentoo Linux
using latest snapshot.
Somethings *definately* wrong here, just need to figure out what.
- Davey
Previous Comments:
[2003-09-27 10:23:59] [EMAIL PROTECTED]
I've now had it confirmed on *two* Debian Linux boxes with a 20030927
snapshot that the hidden element does NOT get output.
Trying to confirm on other distros, versions of windows and newer FBSD
versions now.
Note: the Expected Result has the extraneous hidden input, please
mentally remove that ;)
- Davey
[2003-09-27 08:36:22] [EMAIL PROTECTED]
RTFM Note: If you want XHTML conformity, remove the form entry and
use the fieldset tags around your form fields.
[2003-09-26 23:20:55] [EMAIL PROTECTED]
Description:
Despite there being no form=fakeentry or form= (as I understand it,
providing no value is the same as giving fakeentry) in
url_rewriter.tags the form hidden element for the PHPSESSID is still
output.
I am trying to use form=action as the url_rewriter.tags and whilst this
IS rewritten correctly, the hidden element is still being inserted. It
seems that the fallback mechanism is faulty.
This has been tested on several builds:
PHP 4.3.3RC4 WinXP
Latest Snapshot (200309270130) WinXP
PHP 4.3.3 FreeBSD
Latest Snapshot (200309270130) FreeBSD
I have also had someone reporting the CORRECT behaviour on Debian with
latest CVS so its quite the puzzle...
- Davey
Reproduce code:
---
?php
session_start();
setcookie('PHPSESSID','',0); /* needed if session.use_cookies is still
on */
?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titleUntitled/title
/head
body
?php
ini_set('url_rewriter.tags','a=href,area=href,frame=src,input=src,form=action,foo=bar');
echo ini_get(url_rewriter.tags) . br /;
if(isset($_GET)) {
var_dump($_GET);
}
?
form action=?php echo $_SERVER['PHP_SELF']; ? method=get
p
Foo: input type=text name=foo value= /
br /
Bar: input type=text name=bar value= /
br /
input type=submit value=Test! /
/p
foo href=foo.php bar=null /
/form
/body
/html
Expected result:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titleUntitled/title
/head
body
a=href,area=href,frame=src,input=src,form=action,foo=barbr
/array(0) {
}
form
action=/test/url_rewrite_form_action.php?PHPSESSID=6a5b43d2aef8e2e3158e44fbd3df5d9d
method=getinput type=hidden name=PHPSESSID
value=6a5b43d2aef8e2e3158e44fbd3df5d9d /
p
Foo: input type=text name=foo value= /
br /
Bar: input type=text name=bar value= /
br /
input type=submit value=Test! /
/p
foo href=foo.php
bar=null?PHPSESSID=6a5b43d2aef8e2e3158e44fbd3df5d9d /
/form
/body
/html
Actual result:
--
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titleUntitled/title
/head
body
a=href,area=href,frame=src,input=src,form=action,foo=barbr
/array(0) {
}
form
action=/test/url_rewrite_form_action.php?PHPSESSID=6a5b43d2aef8e2e3158e44fbd3df5d9d
method=getinput type=hidden name=PHPSESSID
value=6a5b43d2aef8e2e3158e44fbd3df5d9d /
p
Foo: input type=text name=foo value= /
br /
Bar: input type=text name=bar value= /
br /
input type=submit value=Test! /
/p
#25176 [Bgs-Opn]: CLI Crashes with entry point not found in php4ts.dll
ID: 25176 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Reproducible crash Operating System: WinXP Pro SP1 PHP Version: 5CVS-2003-08-20 (dev) New Comment: Uhm... php4ts.dll is what is in the win32 PHP5 zip file, with a version of 5.0.0 - Davey Previous Comments: [2003-08-20 07:59:04] [EMAIL PROTECTED] You mixed up .dlls from sever releases. Not a bug. [2003-08-20 07:48:17] [EMAIL PROTECTED] Description: Running the CLI (with or without flags or input) always brings up the error: The procedure entry point _zend_hash_init could not be located in the dynamic link library php4ts.dll. - Davey Reproduce code: --- C:\web\testc:\php5\cli\php.exe -v [enter] [error] C:\web\test Expected result: C:\web\testc:\php5\cli\php.exe -v [enter] PHP 5.0.0b2-dev (cli) (built: Aug 20 2003 12:10:03) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies C:\web\test Actual result: -- Error message pops up with error The procedure entry point _zend_hash_init could not be located in the dynamic link library php4ts.dll. -- Edit this bug report at http://bugs.php.net/?id=25176edit=1
#25176 [Bgs-Opn]: CLI Crashes with entry point not found in php4ts.dll
ID: 25176 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Zend Engine 2 problem Operating System: WinXP Pro SP1 PHP Version: 5CVS-2003-08-20 (dev) Assigned To: zeev New Comment: Then there is something else at play here. I keep my PHP installs in seperate folders like this: c:\php4\ c:\php5\ I do not move php4ts.dll to system32 or anything, it should use the php4ts.dll in the c:\php*\ folder depending on which binary I run (PHP4 or PHP5). It appears that php5 is *not* using the php4ts.dll in c:\php5 (note the cli binary is in c:\php5\cli\php.exe) and indeed when I remove all other php4ts.dll's from my system I get: This application has failed to start because php4ts.dll was not found. Re-installing the application may fix this problem. I am now going to check which php4ts.dll it is detecting (I have quite a few ;) and perhaps I can see why (i.e. if its the one from ZDE its most likely that that .dll is registered with the OS and the one with php5 is not, however PHP4 doesn't suffer from this, so something can be done to fix this) - Davey Previous Comments: [2003-08-20 18:12:54] [EMAIL PROTECTED] edink hit it on the head - it's not a bug, you're mixing binaries from different builds. In Windows there's a simple rule - if it builds, there are no missing symbols, they just can't exist. If there are missing symbols - the build would fail. The only situation where you can get missing symbols is if you mix different successfully-built binaries. [2003-08-20 17:55:04] [EMAIL PROTECTED] Zeev, you touched that stuff on 18th of August.. [2003-08-20 16:31:28] [EMAIL PROTECTED] I too also experienced this error in the php/php-cli dists. I also must note that the internal socket support throws a starnge error in the newer snaps as well. ~ Andrew [2003-08-20 16:21:08] [EMAIL PROTECTED] Uhm... php4ts.dll is what is in the win32 PHP5 zip file, with a version of 5.0.0 - Davey [2003-08-20 07:59:04] [EMAIL PROTECTED] You mixed up .dlls from sever releases. Not a bug. 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/25176 -- Edit this bug report at http://bugs.php.net/?id=25176edit=1
#25176 [Opn]: CLI Crashes with entry point not found in php4ts.dll
ID: 25176 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Zend Engine 2 problem Operating System: WinXP Pro SP1 PHP Version: 5CVS-2003-08-20 (dev) Assigned To: zeev New Comment: Note that this *only* happens with the CLI for me. So is there some difference in how this binary detects php4ts.dll to how the cgi one does? - Davey Previous Comments: [2003-08-20 18:55:51] [EMAIL PROTECTED] OK, it seems that it finds my ZDE php4ts.dll in c:\program files\zend\bin is the one its finding (note that it didn't find the one in c:\program files\zend\bin) It errors with: The procedure entry point zend_uv could not be located in the dynamic link library php4ts.dll - presumably because that php4ts.dll is from 4.2.2 (IIRC). If I then restore my c:\php4\php4ts.dll is seems to find that one instead because the error goes back to the original one reported. Could this be %PATH% related? Or is PHP5 looking for php4ts.dll differently to PHP4? Note that PHP4 *also* finds the ZDE one (and errors with the same error) if c:\php4\php4ts.dll is not there. Something is going on here. - Davey [2003-08-20 18:50:16] [EMAIL PROTECTED] Then there is something else at play here. I keep my PHP installs in seperate folders like this: c:\php4\ c:\php5\ I do not move php4ts.dll to system32 or anything, it should use the php4ts.dll in the c:\php*\ folder depending on which binary I run (PHP4 or PHP5). It appears that php5 is *not* using the php4ts.dll in c:\php5 (note the cli binary is in c:\php5\cli\php.exe) and indeed when I remove all other php4ts.dll's from my system I get: This application has failed to start because php4ts.dll was not found. Re-installing the application may fix this problem. I am now going to check which php4ts.dll it is detecting (I have quite a few ;) and perhaps I can see why (i.e. if its the one from ZDE its most likely that that .dll is registered with the OS and the one with php5 is not, however PHP4 doesn't suffer from this, so something can be done to fix this) - Davey [2003-08-20 18:12:54] [EMAIL PROTECTED] edink hit it on the head - it's not a bug, you're mixing binaries from different builds. In Windows there's a simple rule - if it builds, there are no missing symbols, they just can't exist. If there are missing symbols - the build would fail. The only situation where you can get missing symbols is if you mix different successfully-built binaries. [2003-08-20 17:55:04] [EMAIL PROTECTED] Zeev, you touched that stuff on 18th of August.. [2003-08-20 16:31:28] [EMAIL PROTECTED] I too also experienced this error in the php/php-cli dists. I also must note that the internal socket support throws a starnge error in the newer snaps as well. ~ Andrew 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/25176 -- Edit this bug report at http://bugs.php.net/?id=25176edit=1
#22554 [NEW]: Show Source Anchors
From: davey at its-explosive dot net
Operating system: n/a
PHP version: 5CVS-2003-03-05 (dev)
PHP Bug Type: Feature/Change Request
Bug description: Show Source Anchors
I think that a way to enhance PHP5 in the small area that is show_source()
is not (just) to make it valid/cleaner HTML as has no doubht been
requested before, but I would also like to see anchors placed in the
document, to allow people to link to specific parts of their documents,
the main one I can think of is namespace foo { } class foo { } and
function foo { } - by being able to link to these specifically like:
http://www.someurl.tld/source.phps#function_foo or #class_foo would make
it easier to show specific parts of your code to people...
Don't know what you think... just seems that some additional functionality
in show_source()/phps could help collabaritive debugging such as over IRC
or through forums...
- Davey
--
Edit bug report at http://bugs.php.net/?id=22554edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22554r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22554r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22554r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22554r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22554r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22554r=support
Expected behavior: http://bugs.php.net/fix.php?id=22554r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22554r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22554r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22554r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22554r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22554r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22554r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22554r=gnused
#22176 [NEW]: Website Language Selection?
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.3.0 PHP Bug Type: Feature/Change Request Bug description: Website Language Selection? I was wondering if it'd be possible to make urls like this: http://www.php.net/manual/*/function.parse-ini-file.php and then when someone goes to that link, it displays a list of languages to choose from, then shows the file being requested in the chosen language... It will make linking to the manual much easier, especially on multi-lingual sites. Just a thought... not much work. - Davey -- Edit bug report at http://bugs.php.net/?id=22176edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22176r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22176r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22176r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22176r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22176r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22176r=support Expected behavior: http://bugs.php.net/fix.php?id=22176r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22176r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22176r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22176r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22176r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22176r=dst IIS Stability: http://bugs.php.net/fix.php?id=22176r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22176r=gnused
#20893 [NEW]: Strings as Arrays...
From: [EMAIL PROTECTED]
Operating system: All
PHP version: 4.3.0RC2
PHP Bug Type: Feature/Change Request
Bug description: Strings as Arrays...
This is probably a strange feature request, but I think it should be given
a lot of thought, if it has not done so already.
The request is this:
strings should be treated as arrays of characters (which they are) when
given as the arguement for functions which work on arrays.
so for example:
function foo ($chr) {
echo $chr . br /\n;
}
$string = bar;
array_walk($string,foo); would give the result:
b
a
r
Also, to be able to do this with strings:
$string = fo;
$string{} = o;
so that
$string == foo == TRUE
Also, another thing that comes up often, is when trying to do this:
$string = foo;
foreach ($string as $i) {
echo $string .br /\n;
}
does not work, and you have to do:
$string = foo;
for($i = 0;$i = strlen($string);$i++) {
echo $string{$i} .br /\n;
}
like I said, give this some thought, perhaps toss it around on php-dev
etc..
- Davey
--
Edit bug report at http://bugs.php.net/?id=20893edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20893r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20893r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20893r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20893r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20893r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20893r=support
Expected behavior: http://bugs.php.net/fix.php?id=20893r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20893r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20893r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20893r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20893r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20893r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20893r=isapi
#20893 [Opn]: Strings as Arrays...
ID: 20893
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 4.3.0RC2
New Comment:
small code correction:
$string = foo;
foreach ($string as $i) {
echo $i .br /\n;
}
Previous Comments:
[2002-12-08 20:56:13] [EMAIL PROTECTED]
This is probably a strange feature request, but I think it should be
given a lot of thought, if it has not done so already.
The request is this:
strings should be treated as arrays of characters (which they are) when
given as the arguement for functions which work on arrays.
so for example:
function foo ($chr) {
echo $chr . br /\n;
}
$string = bar;
array_walk($string,foo); would give the result:
b
a
r
Also, to be able to do this with strings:
$string = fo;
$string{} = o;
so that
$string == foo == TRUE
Also, another thing that comes up often, is when trying to do this:
$string = foo;
foreach ($string as $i) {
echo $string .br /\n;
}
does not work, and you have to do:
$string = foo;
for($i = 0;$i = strlen($string);$i++) {
echo $string{$i} .br /\n;
}
like I said, give this some thought, perhaps toss it around on php-dev
etc..
- Davey
--
Edit this bug report at http://bugs.php.net/?id=20893edit=1
#20377 [WFx-Opn]: ini settings, per virtualhost
ID: 20377 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Won't fix +Status: Open Bug Type: Feature/Change Request Operating System: All PHP Version: 4.3.0-pre2 New Comment: /me points to php_admin_flag and php_admin_value - Davey Previous Comments: [2002-11-15 21:25:35] [EMAIL PROTECTED] .htaccess also falls in the PERDIR class, and it's not a good idea to allow setting open_basedir and the other settings from this file especially for ISPs and stuff. --derick [2002-11-11 20:15:05] [EMAIL PROTECTED] this is a feature I've put a lot of thought into and I really think webhosts specifically will benefit from this feature. It's basically allowing certain ini directives to be set using php_admin_flag/value on a virtualhost basis. The config options I think should be modified are these: open_basedir session.save_path upload_tmp_dir auto_prepend_file auto_append_file I don't know whats involved in changing these, but I would assume it's not a major change. I would love to see this in the forthcoming 4.3 release... - Davey -- Edit this bug report at http://bugs.php.net/?id=20377edit=1
#20377 [NEW]: ini settings, per virtualhost
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.3.0-pre2 PHP Bug Type: Feature/Change Request Bug description: ini settings, per virtualhost this is a feature I've put a lot of thought into and I really think webhosts specifically will benefit from this feature. It's basically allowing certain ini directives to be set using php_admin_flag/value on a virtualhost basis. The config options I think should be modified are these: open_basedir session.save_path upload_tmp_dir auto_prepend_file auto_append_file I don't know whats involved in changing these, but I would assume it's not a major change. I would love to see this in the forthcoming 4.3 release... - Davey -- Edit bug report at http://bugs.php.net/?id=20377edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20377r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20377r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20377r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20377r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20377r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20377r=support Expected behavior: http://bugs.php.net/fix.php?id=20377r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20377r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20377r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20377r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20377r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20377r=dst IIS Stability: http://bugs.php.net/fix.php?id=20377r=isapi
