Req #41082 [Com]: url_rewriter.tags are wrong
Edit report at https://bugs.php.net/bug.php?id=41082&edit=1
ID: 41082
Comment by: der-coole-carl at gmx dot net
Reported by:der-coole-carl at gmx dot net
Summary:url_rewriter.tags are wrong
Status: Feedback
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
No, today I think this whole feature is bad.
Previous Comments:
[2012-03-29 09:27:53] yohg...@php.net
Do you still want this feature?
[2007-04-14 00:21:27] der-coole-carl at gmx dot net
Description:
it would be good if you can change
url_rewriter.tags from
a=href,area=href,frame=src,input=src,form=,fieldset=
to
a=href,area=href,frame=src,input=src,form=action,fieldset=
if i use session_use_trans_sid it doesn't put the SID in my forms.. that's
maybe you forgot the form=_action_
i don't know if it matters:
i use: ob_start("ob_gzhandler"); to compress my code.. maybe this is relevant
Reproduce code:
---
in this example the user have to deactivate cookies
Expected result:
i expect that the target url will be: test.php?phpsessid=1234
Actual result:
--
actual the target url is test.php
--
Edit this bug report at https://bugs.php.net/bug.php?id=41082&edit=1
[PHP-BUG] Bug #55105 [NEW]: ActiveRecord\DatabaseException
From:
Operating system: RedHat Enterprise 5.5
PHP version: 5.3.6
Package: PDO related
Bug Type: Bug
Bug description:ActiveRecord\DatabaseException
Description:
---
>From manual page: http://www.php.net/ref.pdo-oci
---
I built PHP 5.3.6 from Source using the following commands in a bash
script. The
compile, install process ran without errors.
#!/bin/bash
export ORACLE_HOME=/oracle/product/10.2.0
export MYSQL_DIR=/usr/local/mysql-5.1.52
export PHP_HOME=/usr/local/php-5.3.6
./configure \
--prefix=$PHP_HOME \
--with-apxs2=/usr/sbin/apxs \
--with-mysql-sock=/tmp/mysql.sock \
--with-oci8=$ORACLE_HOME \
--with-mysql=$MYSQL_DIR \
--with-mysqli=$MYSQL_DIR/bin/mysql_config \
--with-pear=$PHP_HOME/lib/php \
--with-libdir=lib64 \
--with-ldap \
--with-curl \
--enable-mbstring \
--with-pdo-mysql=$MYSQL_DIR \
--with-pdo-oci=$ORACLE_HOME
make
make install
Test script:
---
require_once "php-activerecord/ActiveRecord.php";
date_default_timezone_set ( "America/Chicago" );
ActiveRecord\Config::initialize(function($cfg) {
$cfg->set_model_directory("models");
$cfg->set_connections(array( "oracle" =>
"oci://envsviewer:guidant3@stpsn155/latenvs" ));
$cfg->set_default_connection("oracle");
});
Expected result:
A successful connection to the Oracle DB.
Actual result:
--
Fatal error: Uncaught exception 'ActiveRecord\DatabaseException' with
message
'exception 'PDOException' with message 'SQLSTATE[]: pdo_oci_handle_factory:
OCI_INVALID_HANDLE (/usr/local/src/php-5.3.6/ext/pdo_oci/oci_driver.c:579)'
in
/var/www/html/latenvsdev/classes/php-activerecord/lib/adapters/OciAdapter.php:25
Stack trace: #0 /var/www/html/latenvsdev/classes/php-
activerecord/lib/adapters/OciAdapter.php(25): PDO-
>__construct('oci:dbname=//st...', 'envsviewer', 'guidant3', Array) #1
/var/www/html/latenvsdev/classes/php-activerecord/lib/Connection.php(101):
ActiveRecord\OciAdapter->__construct(Object(stdClass)) #2
/var/www/html/latenvsdev/classes/php-activerecord/lib/ConnectionManager.php(33):
ActiveRecord\Connection::instance('oci://envsviewe...') #3
/var/www/html/latenvsdev/classes/php-activerecord/lib/Table.php(103):
ActiveRecord\ConnectionManager::get_connection(NULL) #4
/var/www/html/latenvsdev/classes/php-activerecord/lib/Table.php(80):
ActiveRecord\Table->reestablish_connection(false) #5
/var/www/html/latenvsdev/cla in /var/www/html/latenvsdev/classes/php-
activerecord/lib/Connection.php on line 109
--
Edit bug report at https://bugs.php.net/bug.php?id=55105&edit=1
--
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55105&r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55105&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55105&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55105&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55105&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55105&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55105&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55105&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55105&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55105&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55105&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55105&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55105&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55105&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55105&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55105&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55105&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55105&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55105&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55105&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55105&r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55105&r=trysnapshot54
#42704 [Opn->Bgs]: Memory exhausted with --with-sybase=/usr/local/freetds and --enable-soap used
ID: 42704
User updated by: carl dot washburn at iridium dot com
Reported By: carl dot washburn at iridium dot com
-Status: Open
+Status: Bogus
Bug Type: Sybase (dblib) related
Operating System: Solaris 10
PHP Version: 5.2.4
New Comment:
Mea Culpa.
When compiling multiple configurations I discovered that the freetds
drivers were different versions between my production and test servers.
After regressing to libsybdb.so.4.0.0 the issue was resolved. Thank you
for your help.
Previous Comments:
[2007-09-19 14:31:01] carl dot washburn at iridium dot com
Currently doing a recompile to have apples to apples comparison with
and without soap. Will post config lines when finished.
Soap Section of php.ini:
[soap]
soap.wsdl_cache_enabled=1
soap.wsdl_cache_dir="/tmp"
soap.wsdl_cache_ttl=86400
[2007-09-19 13:32:02] [EMAIL PROTECTED]
Since ext/soap has absolutely nothing to do with ext/sybase it sounds a
bit far fetched that simply disabling ext/soap in the build would have
any effect on this. Are you sure you don't have some prepend/append
stuff set in your php.ini that might be doing something with soap? What
is the full configure line that causes the problem? And what is the full
configure line that works?
[2007-09-18 23:10:30] carl dot washburn at iridium dot com
Added info:
This is 64 bit php build. 32 bit has not been tested.
Code that reproduces bug:
[2007-09-18 19:16:16] carl dot washburn at iridium dot com
Description:
I have seen this problem in both 5.2.3 and 5.2.4.
If I compile php with:
--with-sybase=/usr/local/freetds
--enable-soap,
I receive the following when calling sybase_query:
"Allowed memory size of 104857600 bytes exhausted (tried to allocate
4722688 bytes)"
If I use:
ini_set("memory_limit","-1");
ini_set("max_execution_time","-1");
I receive from the same call to sybase_query:
"Out of memory (allocated 8156348416) (tried to allocate 370671616
bytes)" .
The query returns requested information if I do not enable soap
extensions.
Expected result:
Query to return the same information as without --enable-soap.
Actual result:
--
Query fails.
--
Edit this bug report at http://bugs.php.net/?id=42704&edit=1
#42704 [Fbk->Opn]: Memory exhausted with --with-sybase=/usr/local/freetds and --enable-soap used
ID: 42704
User updated by: carl dot washburn at iridium dot com
Reported By: carl dot washburn at iridium dot com
-Status: Feedback
+Status: Open
Bug Type: Sybase (dblib) related
Operating System: Solaris 10
PHP Version: 5.2.4
New Comment:
Currently doing a recompile to have apples to apples comparison with
and without soap. Will post config lines when finished.
Soap Section of php.ini:
[soap]
soap.wsdl_cache_enabled=1
soap.wsdl_cache_dir="/tmp"
soap.wsdl_cache_ttl=86400
Previous Comments:
[2007-09-19 13:32:02] [EMAIL PROTECTED]
Since ext/soap has absolutely nothing to do with ext/sybase it sounds a
bit far fetched that simply disabling ext/soap in the build would have
any effect on this. Are you sure you don't have some prepend/append
stuff set in your php.ini that might be doing something with soap? What
is the full configure line that causes the problem? And what is the full
configure line that works?
[2007-09-18 23:10:30] carl dot washburn at iridium dot com
Added info:
This is 64 bit php build. 32 bit has not been tested.
Code that reproduces bug:
[2007-09-18 19:16:16] carl dot washburn at iridium dot com
Description:
I have seen this problem in both 5.2.3 and 5.2.4.
If I compile php with:
--with-sybase=/usr/local/freetds
--enable-soap,
I receive the following when calling sybase_query:
"Allowed memory size of 104857600 bytes exhausted (tried to allocate
4722688 bytes)"
If I use:
ini_set("memory_limit","-1");
ini_set("max_execution_time","-1");
I receive from the same call to sybase_query:
"Out of memory (allocated 8156348416) (tried to allocate 370671616
bytes)" .
The query returns requested information if I do not enable soap
extensions.
Expected result:
Query to return the same information as without --enable-soap.
Actual result:
--
Query fails.
--
Edit this bug report at http://bugs.php.net/?id=42704&edit=1
#42704 [Opn]: php compiled --with-sybase=/usr/local/freetds --enable-soap memory exhausted
ID: 42704
User updated by: carl dot washburn at iridium dot com
Reported By: carl dot washburn at iridium dot com
Status: Open
Bug Type: Sybase (dblib) related
Operating System: Solaris 10
PHP Version: 5.2.4
New Comment:
Added info:
This is 64 bit php build. 32 bit has not been tested.
Code that reproduces bug:
Previous Comments:
[2007-09-18 19:16:16] carl dot washburn at iridium dot com
Description:
I have seen this problem in both 5.2.3 and 5.2.4.
If I compile php with:
--with-sybase=/usr/local/freetds
--enable-soap,
I receive the following when calling sybase_query:
"Allowed memory size of 104857600 bytes exhausted (tried to allocate
4722688 bytes)"
If I use:
ini_set("memory_limit","-1");
ini_set("max_execution_time","-1");
I receive from the same call to sybase_query:
"Out of memory (allocated 8156348416) (tried to allocate 370671616
bytes)" .
The query returns requested information if I do not enable soap
extensions.
Expected result:
Query to return the same information as without --enable-soap.
Actual result:
--
Query fails.
--
Edit this bug report at http://bugs.php.net/?id=42704&edit=1
#42704 [NEW]: php compiled --with-sybase=/usr/local/freetds --enable-soap memory exhausted
From: carl dot washburn at iridium dot com
Operating system: Solaris 10
PHP version: 5.2.4
PHP Bug Type: Sybase (dblib) related
Bug description: php compiled --with-sybase=/usr/local/freetds --enable-soap
memory exhausted
Description:
I have seen this problem in both 5.2.3 and 5.2.4.
If I compile php with:
--with-sybase=/usr/local/freetds
--enable-soap,
I receive the following when calling sybase_query:
"Allowed memory size of 104857600 bytes exhausted (tried to allocate
4722688 bytes)"
If I use:
ini_set("memory_limit","-1");
ini_set("max_execution_time","-1");
I receive from the same call to sybase_query:
"Out of memory (allocated 8156348416) (tried to allocate 370671616 bytes)"
.
The query returns requested information if I do not enable soap
extensions.
Expected result:
Query to return the same information as without --enable-soap.
Actual result:
--
Query fails.
--
Edit bug report at http://bugs.php.net/?id=42704&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42704&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42704&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42704&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42704&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42704&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42704&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42704&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42704&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42704&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42704&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42704&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42704&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42704&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42704&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42704&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42704&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42704&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42704&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42704&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42704&r=mysqlcfg
#41175 [NEW]: SimpleXmlElement->addAttribute() doesn't allow empty strings
From: carl at thep dot lu dot se
Operating system: Linux
PHP version: 5.2.1
PHP Bug Type: SimpleXML related
Bug description: SimpleXmlElement->addAttribute() doesn't allow empty strings
Description:
A call like addAttribute("attrname", "") results in
"PHP Warning: SimpleXMLElement::addAttribute(): Attribute name and value
are required". In addition to the warning, the attribute is discarded.
Reproduce code:
---
");
$xml->addAttribute("src", "foo");
$xml->addAttribute("alt", "");
echo $xml->asXML()."\n";
?>
Expected result:
Actual result:
--
PHP Warning: SimpleXMLElement::addAttribute(): Attribute name and value
are required in [...]/test.php on line 4
--
Edit bug report at http://bugs.php.net/?id=41175&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41175&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41175&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41175&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41175&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41175&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41175&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41175&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41175&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41175&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41175&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41175&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41175&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41175&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41175&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41175&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41175&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41175&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41175&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41175&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41175&r=mysqlcfg
#41082 [NEW]: url_rewriter.tags are wrong
From: der-coole-carl at gmx dot net
Operating system:
PHP version: 5.2.1
PHP Bug Type: Feature/Change Request
Bug description: url_rewriter.tags are wrong
Description:
it would be good if you can change
url_rewriter.tags from
a=href,area=href,frame=src,input=src,form=,fieldset=
to
a=href,area=href,frame=src,input=src,form=action,fieldset=
if i use session_use_trans_sid it doesn't put the SID in my forms.. that's
maybe you forgot the form=_action_
i don't know if it matters:
i use: ob_start("ob_gzhandler"); to compress my code.. maybe this is
relevant
Reproduce code:
---
in this example the user have to deactivate cookies
Expected result:
i expect that the target url will be: test.php?phpsessid=1234
Actual result:
--
actual the target url is test.php
--
Edit bug report at http://bugs.php.net/?id=41082&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41082&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41082&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41082&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41082&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41082&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41082&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41082&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41082&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41082&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41082&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41082&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41082&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41082&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41082&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41082&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41082&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41082&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41082&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41082&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41082&r=mysqlcfg
#29291 [NEW]: get_class_vars() return names with NULLs
From: carl dot b at h2data dot com
Operating system:
PHP version: 5.0.0
PHP Bug Type: Zend Engine 2 problem
Bug description: get_class_vars() return names with NULLs
Description:
The keys in the array returned by get_class_vars() contains NULLs if the
field (or variable) is protected or private.
A more exact description of the syntax of the keys is listed below.
protected: "\x00*\x00"
private: "\x00\x00"
public: ""
Ok, it's a way to determine the access modifiers of the fields, but as the
strings starts with NULL, most PHP functions will think the string is empty
as it begins with a null (null-terminated strings). Example is
preg_match().
In any case, get_class_vars() isn't supposed to do this kind of work; so
any hint of the access shouldn't be included.
BTW, is get_class_vars() supposed to only return public fields? As the
docs doesn't mentions it, I've assumed not.
Reproduce code:
---
$value) {
echo "$name : $value\n";
}
?>
Expected result:
AProtectedField : orange
APrivateField : apple
APublicField : strawberry
Actual result:
--
\x00*\x00AProtectedField : orange
\x00MyClass\x00APrivateField : apple
APublicField : strawberry
--
Edit bug report at http://bugs.php.net/?id=29291&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29291&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29291&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29291&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29291&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29291&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29291&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29291&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29291&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29291&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29291&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29291&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29291&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29291&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29291&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29291&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29291&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29291&r=float
#25110 [NEW]: $_SESSION can be changed indirectly
From: carl at freeideas dot com
Operating system: OSX and WIN2K
PHP version: 4.3.2
PHP Bug Type: Session related
Bug description: $_SESSION can be changed indirectly
Description:
When register_globals is on, and after a session has already been started,
$_SESSION values can be changed indirectly.
$_SESSION['userID'] = 'carl';
$userID = $_SESSION['userID'];
$userID = 'HAXOR';
# now $_SESSION['userID'] is 'HAXOR'
To me, this seems like a bad thing.
Happens under Mac OS 10.2, w/ PHP 4.3.2
Happens under Win2K w/ PHP 4.3.2
Doesn't happen under Linux w/ PHP 4.2.3
Reproduce code:
---
\n";
$userID = 'HAXOR';
print "after: ". $_SESSION['userID'] ."\n";
if ( $_SESSION['userID']=='HAXOR' ) { print "bad"; }
# seems very wrong that $_SESSION['userID'] was changed
?>
Expected result:
After I run the script and reload it once, I should not see "bad" because
changing $userID should not change $_SESSION['userID'].
Actual result:
--
bad
--
Edit bug report at http://bugs.php.net/?id=25110&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25110&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25110&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25110&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25110&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25110&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25110&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25110&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25110&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25110&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25110&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25110&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25110&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25110&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25110&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25110&r=gnused
#22747 [Fbk->Opn]: Getting maximum execution timeout errors on lines which shouldnt be doing so
ID: 22747 User updated by: carl at voodoomedia dot co dot uk Reported By: carl at voodoomedia dot co dot uk -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2000 SP3 PHP Version: 4.3.2-RC New Comment: Hi there, I'm using Apache 1.3.27 on a windows 2000 SP3 machine, dual P3 1.6ghz processors and 1.5GB RAM PHP is loading as an apache module and i've tried 4.3.1 and 4.3.2 latest cvs binaries. the differences in my ini from php-dist are short_open_tags = Off precision = 14 zlib_output_compression = on (but only did this last night wsa off until then) allow_call_time_pass_reference = off max_execution_time = 40 error_reporting = E_ALL display_errors = Off log_errors = On ignore_repeated_errors = on error_log = e:\php.log register_argc_argv = off magic_quotes_runtime = on include_path = e:\www\ doc_root = e:\www\ extensions_dir = c:\php\extensions upload_max_file_size=4M default_socket_timeout=30 SMTP=[ip to local smtp server] session_save_path = c:\php\sessions session.gc_dividend = 1000 session.bug_compat_warn = 0 (makes no difference, still see em) Thanks Previous Comments: [2003-03-25 06:46:39] [EMAIL PROTECTED] What webserver is used? How is PHP configured in it? Are you using CGI binary or a module? What is the diff -u between the php.ini-dist file and your php.ini ? [2003-03-25 05:51:58] carl at voodoomedia dot co dot uk I'm afraid that "You're doing something wrong" just isn't an acceptable answer. It's a problem with PHP's session handler or serializer for sure. I can replicate it by using this script '; echo 'click here to reload ?> If I call that page from an automated page refresh script that I have at some point within an hour I will get [25-Mar-2003 11:37:27] PHP Fatal error: Maximum execution time of 40 seconds exceeded in e:\www\sesstest.php on line 2. [2003-03-18 11:38:50] [EMAIL PROTECTED] You're doing something wrong, ask support questions on the mailing lists. ---- [2003-03-18 09:32:54] carl at voodoomedia dot co dot uk It happens without zend installed, I installed that last night in the hope that it would solve the time outs by speeding things up :((( [2003-03-18 09:23:12] [EMAIL PROTECTED] Disable the ZendOptimizer and try the code again. 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/22747 -- Edit this bug report at http://bugs.php.net/?id=22747&edit=1
#22747 [Bgs->Opn]: Getting maximum execution timeout errors on lines which shouldnt be doing so
ID: 22747 User updated by: carl at voodoomedia dot co dot uk Reported By: carl at voodoomedia dot co dot uk -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2000 SP3 PHP Version: 4.3.2-RC New Comment: I'm afraid that "You're doing something wrong" just isn't an acceptable answer. It's a problem with PHP's session handler or serializer for sure. I can replicate it by using this script '; echo 'click here to reload ?> If I call that page from an automated page refresh script that I have at some point within an hour I will get [25-Mar-2003 11:37:27] PHP Fatal error: Maximum execution time of 40 seconds exceeded in e:\www\sesstest.php on line 2. Previous Comments: [2003-03-18 11:38:50] [EMAIL PROTECTED] You're doing something wrong, ask support questions on the mailing lists. ---- [2003-03-18 09:32:54] carl at voodoomedia dot co dot uk It happens without zend installed, I installed that last night in the hope that it would solve the time outs by speeding things up :((( [2003-03-18 09:23:12] [EMAIL PROTECTED] Disable the ZendOptimizer and try the code again. [2003-03-17 19:49:47] [EMAIL PROTECTED] I can't reproduce this...what have you changed in your php.ini compared to the php.ini-dist ?? Can you provide a complete but short example of code that can be used to reproduce this? ---- [2003-03-17 15:26:14] carl at voodoomedia dot co dot uk Thanks for that, I tried the latest windows snapshot as you suggested but it did not fix the problem, latest one was a timeout on this line!!! echo ''; 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/22747 -- Edit this bug report at http://bugs.php.net/?id=22747&edit=1
#22747 [Fbk->Opn]: Getting maximum execution timeout errors on lines which shouldnt be doing so
ID: 22747
User updated by: carl at voodoomedia dot co dot uk
Reported By: carl at voodoomedia dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows 2000 SP3
PHP Version: 4.3.2-RC
New Comment:
It happens without zend installed, I installed that last night in the
hope that it would solve the time outs by speeding things up :(((
Previous Comments:
[2003-03-18 09:23:12] [EMAIL PROTECTED]
Disable the ZendOptimizer and try the code again.
[2003-03-18 03:26:29] carl at voodoomedia dot co dot uk
There is no 1 specific piece of code that reproduces the error, it just
happens a lot in the log files, on lines such as the following
session_register("tmp_username");
include_once('include\inc_showheader.php');
I seem to have a *lot* of timeouts in the logs for the following line
if (!isset($_SESSION['tmp_username'])) $_SESSION['tmp_username'] = '';
I changed all my session_register code to the above so that I use
$_SESSION everywhere.
Here is my php.ini
Thanks
[PHP]
;;;
; About this file ;
;;;
;
; This is the recommended, PHP 4-style version of the php.ini-dist
file. It
; sets some non standard settings, that make PHP more efficient, more
secure,
; and encourage cleaner coding.
; The price is that with these settings, PHP may be incompatible with
some
; applications, and sometimes, more difficult to develop with. Using
this
; file is warmly recommended for production sites. As all of the
changes from
; the standard settings are thoroughly documented, you can go over each
one,
; and decide whether you want to use it or not.
;
; For general information about the php.ini file, please consult the
php.ini-dist
; file, included in your PHP distribution.
;
; This file is different from the php.ini-dist file in the fact that it
features
; different values for several directives, in order to improve
performance, while
; possibly breaking compatibility with the standard out-of-the-box
behavior of
; PHP 3. Please make sure you read what's different, and modify your
scripts
; accordingly, if you decide to use this file instead.
;
; - register_globals = Off [Security, Performance]
; Global variables are no longer registered for input data (POST,
GET, cookies,
; environment and other server variables). Instead of using $foo,
you must use
; you can use $_REQUEST["foo"] (includes any variable that arrives
through the
; request, namely, POST, GET and cookie variables), or use one of
the specific
; $_GET["foo"], $_POST["foo"], $_COOKIE["foo"] or $_FILES["foo"],
depending
; on where the input originates. Also, you can look at the
; import_request_variables() function.
; Note that register_globals is going to be depracated (i.e.,
turned off by
; default) in the next version of PHP, because it often leads to
security bugs.
; Read http://php.net/manual/en/security.registerglobals.php for
further
; information.
; - display_errors = Off [Security]
; With this directive set to off, errors that occur during the
execution of
; scripts will no longer be displayed as a part of the script
output, and thus,
; will no longer be exposed to remote users. With some errors, the
error message
; content may expose information about your script, web server, or
database
; server that may be exploitable for hacking. Production sites
should have this
; directive set to off.
; - log_errors = On[Security]
; This directive complements the above one. Any errors that occur
during the
; execution of your script will be logged (typically, to your
server's error log,
; but can be configured in several ways). Along with setting
display_errors to off,
; this setup gives you the ability to fully understand what may
have gone wrong,
; without exposing any sensitive information to remote users.
; - output_buffering = 4096[Performance]
; Set a 4KB output buffer. Enabling output buffering typically
results in less
; writes, and sometimes less packets sent on the wire, which can
often lead to
; better performance. The gain this directive actually yields
greatly depends
; on which Web server you're working with, and what kind of scripts
you're using.
; - register_argc_argv = Off [Performance]
; Disables registration of the somewhat redundant $argv and $argc
global
; variables.
; - magic_quotes_gpc = Off [Performance]
; Input data is no longer escaped with slashes so that it can be
sent into
; SQL databases without further manipulation. Instead, you should
use the
; fun
#22747 [Fbk->Opn]: Getting maximum execution timeout errors on lines which shouldnt be doing so
ID: 22747
User updated by: carl at voodoomedia dot co dot uk
Reported By: carl at voodoomedia dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows 2000 SP3
PHP Version: 4.3.2-RC
New Comment:
There is no 1 specific piece of code that reproduces the error, it just
happens a lot in the log files, on lines such as the following
session_register("tmp_username");
include_once('include\inc_showheader.php');
I seem to have a *lot* of timeouts in the logs for the following line
if (!isset($_SESSION['tmp_username'])) $_SESSION['tmp_username'] = '';
I changed all my session_register code to the above so that I use
$_SESSION everywhere.
Here is my php.ini
Thanks
[PHP]
;;;
; About this file ;
;;;
;
; This is the recommended, PHP 4-style version of the php.ini-dist
file. It
; sets some non standard settings, that make PHP more efficient, more
secure,
; and encourage cleaner coding.
; The price is that with these settings, PHP may be incompatible with
some
; applications, and sometimes, more difficult to develop with. Using
this
; file is warmly recommended for production sites. As all of the
changes from
; the standard settings are thoroughly documented, you can go over each
one,
; and decide whether you want to use it or not.
;
; For general information about the php.ini file, please consult the
php.ini-dist
; file, included in your PHP distribution.
;
; This file is different from the php.ini-dist file in the fact that it
features
; different values for several directives, in order to improve
performance, while
; possibly breaking compatibility with the standard out-of-the-box
behavior of
; PHP 3. Please make sure you read what's different, and modify your
scripts
; accordingly, if you decide to use this file instead.
;
; - register_globals = Off [Security, Performance]
; Global variables are no longer registered for input data (POST,
GET, cookies,
; environment and other server variables). Instead of using $foo,
you must use
; you can use $_REQUEST["foo"] (includes any variable that arrives
through the
; request, namely, POST, GET and cookie variables), or use one of
the specific
; $_GET["foo"], $_POST["foo"], $_COOKIE["foo"] or $_FILES["foo"],
depending
; on where the input originates. Also, you can look at the
; import_request_variables() function.
; Note that register_globals is going to be depracated (i.e.,
turned off by
; default) in the next version of PHP, because it often leads to
security bugs.
; Read http://php.net/manual/en/security.registerglobals.php for
further
; information.
; - display_errors = Off [Security]
; With this directive set to off, errors that occur during the
execution of
; scripts will no longer be displayed as a part of the script
output, and thus,
; will no longer be exposed to remote users. With some errors, the
error message
; content may expose information about your script, web server, or
database
; server that may be exploitable for hacking. Production sites
should have this
; directive set to off.
; - log_errors = On[Security]
; This directive complements the above one. Any errors that occur
during the
; execution of your script will be logged (typically, to your
server's error log,
; but can be configured in several ways). Along with setting
display_errors to off,
; this setup gives you the ability to fully understand what may
have gone wrong,
; without exposing any sensitive information to remote users.
; - output_buffering = 4096[Performance]
; Set a 4KB output buffer. Enabling output buffering typically
results in less
; writes, and sometimes less packets sent on the wire, which can
often lead to
; better performance. The gain this directive actually yields
greatly depends
; on which Web server you're working with, and what kind of scripts
you're using.
; - register_argc_argv = Off [Performance]
; Disables registration of the somewhat redundant $argv and $argc
global
; variables.
; - magic_quotes_gpc = Off [Performance]
; Input data is no longer escaped with slashes so that it can be
sent into
; SQL databases without further manipulation. Instead, you should
use the
; function addslashes() on each input element you wish to send to a
database.
; - variables_order = "GPCS" [Performance]
; The environment variables are not hashed into the
$HTTP_ENV_VARS[]. To access
; environment variables, you can use getenv() instead.
; - error_reporting = E_ALL[Code Cleanliness, Security(?)]
; By default, PHP surpresses errors of type E_NOTICE. These error
messages
; are emitted for non-c
#22747 [Fbk->Opn]: Getting maximum execution timeout errors on lines which shouldnt be doing so
ID: 22747
User updated by: carl at voodoomedia dot co dot uk
Reported By: carl at voodoomedia dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows 2000 SP3
PHP Version: 4.3.0
New Comment:
Thanks for that, I tried the latest windows snapshot as you suggested
but it did not fix the problem, latest one was a timeout on this
line!!!
echo '';
Previous Comments:
[2003-03-17 10:20:55] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-03-17 10:06:52] carl at voodoomedia dot co dot uk
I'm having some very strange issues with maximum execution timeouts.
I've set them to 45 seconds in my php.ini and it's picking these up
fine, but what I am getting is errors telling there that there are
timeouts in lines which I really would not expect any timesout to
happen. for example
[17-Mar-2003 16:00:17] PHP Fatal error: Maximum execution time of 45
seconds exceeded in e:\www\include\inc_sessiondata.php on line 13
and ine 13 in this file is
session_register("tmp_username");
only thing before this line is a session_start();
so I cannot see how a 45 second timeout could happen there?
I've also had a timeout when just doing includes as below
include_once('include\inc_showheader.php');
showheader.php just includes HTML and only PHP code in there are simple
echo's
So i'm confused as to why a timeout would happen with the above
situations.
--
Edit this bug report at http://bugs.php.net/?id=22747&edit=1
#22747 [NEW]: Getting maximum execution timeout errors on lines which shouldnt be doing so
From: carl at voodoomedia dot co dot uk
Operating system: Windows 2000 SP3
PHP version: 4.3.0
PHP Bug Type: Performance problem
Bug description: Getting maximum execution timeout errors on lines which shouldnt be
doing so
I'm having some very strange issues with maximum execution timeouts. I've
set them to 45 seconds in my php.ini and it's picking these up fine, but
what I am getting is errors telling there that there are timeouts in lines
which I really would not expect any timesout to happen. for example
[17-Mar-2003 16:00:17] PHP Fatal error: Maximum execution time of 45
seconds exceeded in e:\www\include\inc_sessiondata.php on line 13
and ine 13 in this file is
session_register("tmp_username");
only thing before this line is a session_start();
so I cannot see how a 45 second timeout could happen there?
I've also had a timeout when just doing includes as below
include_once('include\inc_showheader.php');
showheader.php just includes HTML and only PHP code in there are simple
echo's
So i'm confused as to why a timeout would happen with the above
situations.
--
Edit bug report at http://bugs.php.net/?id=22747&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22747&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22747&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22747&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22747&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22747&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22747&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22747&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22747&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22747&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22747&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22747&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22747&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22747&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22747&r=gnused
#22435 [Fbk->Csd]: count() is slow when used with large arrays
ID: 22435 User updated by: carl at topthetable dot com Reported By: carl at topthetable dot com -Status: Feedback +Status: Closed Bug Type: Performance problem Operating System: Redhat 7.2 PHP Version: 4.3.1 New Comment: OK, recompiled with the latest STABLE and I got the same results. Then in a flash of inspiration, I remembered that I have xdebug installed on the Linux box with collect_params on - Sure enough, when I turn this option off, the problem goes away. So I'll go away and hide ... Previous Comments: [2003-02-26 10:20:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I tested using this and got pretty same results on both linux and macosx. Please test it.. [2003-02-26 09:55:39] carl at topthetable dot com Thanks for your reply, and better script. Here are my results, showing the times on the Redhat and OSX boxes respectively ... Redhat 7.2 (PIII 700Mhz): 0.000356078147888 3.09110200405 24.5502359867 55.3548690081 136.626052976 ... Gave up waiting. As you can see, this is not correct behaviour. You can clearly see that the time isn't constant, nor increasingly linearly. I therefore say there is something wrong. OSX (iBook, 500Mhz): 0.00040602684021 0.000491976737976 0.000488996505737 0.000484943389893 0.000471949577332 0.000415086746216 0.000434041023254 0.00104403495789 0.000488996505737 0.000432014465332 Avg: 0.00051580667495 This is as per your results. [2003-02-26 09:24:56] [EMAIL PROTECTED] Try this script which actually shows the time _spend_ for count: Results for me: Linux (double Celeron 500Mhz): 0.00995302200317 0.000295042991638 0.000288963317871 0.000303030014038 0.000295042991638 0.000295042991638 0.000294089317322 0.000292062759399 0.000293016433716 0.000355005264282 Avg: 0.00126643180847 MacOSX, PowerPC (1Ghz or faster, not sure): 0.00011193752288818 9.0956687927246E-05 0.00010311603546143 0.00010299682617188 0.00010395050048828 0.00010097026824951 0.00011003017425537 0.00013697147369385 0.00010299682617188 0.00010597705841064 Avg: 0.00010699033737183 Nothing wrong here.. [2003-02-26 08:11:50] carl at topthetable dot com count() is increasingly slow when used to count large arrays. This is using 4.3.1 (compiled from source) on a Redhat 7.2 box. The box has about 80Mb free, so it's not a paging issue. It works as expected on Mac OS X running 4.3.1-dev. Looking at PHP's and Zend's source, I would expect the time taken to return the count() of an array to be similar regardless of the size of the array. Below is a script to demonstrate the problem. -- Edit this bug report at http://bugs.php.net/?id=22435&edit=1
#22435 [Bgs->Opn]: count() is slow when used with large arrays
ID: 22435 User updated by: carl at topthetable dot com Reported By: carl at topthetable dot com -Status: Bogus +Status: Open Bug Type: Performance problem Operating System: Redhat 7.2 PHP Version: 4.3.1 New Comment: Thanks for your reply, and better script. Here are my results, showing the times on the Redhat and OSX boxes respectively ... Redhat 7.2 (PIII 700Mhz): 0.000356078147888 3.09110200405 24.5502359867 55.3548690081 136.626052976 ... Gave up waiting. As you can see, this is not correct behaviour. You can clearly see that the time isn't constant, nor increasingly linearly. I therefore say there is something wrong. OSX (iBook, 500Mhz): 0.00040602684021 0.000491976737976 0.000488996505737 0.000484943389893 0.000471949577332 0.000415086746216 0.000434041023254 0.00104403495789 0.000488996505737 0.000432014465332 Avg: 0.00051580667495 This is as per your results. Previous Comments: [2003-02-26 09:24:56] [EMAIL PROTECTED] Try this script which actually shows the time _spend_ for count: Results for me: Linux (double Celeron 500Mhz): 0.00995302200317 0.000295042991638 0.000288963317871 0.000303030014038 0.000295042991638 0.000295042991638 0.000294089317322 0.000292062759399 0.000293016433716 0.000355005264282 Avg: 0.00126643180847 MacOSX, PowerPC (1Ghz or faster, not sure): 0.00011193752288818 9.0956687927246E-05 0.00010311603546143 0.00010299682617188 0.00010395050048828 0.00010097026824951 0.00011003017425537 0.00013697147369385 0.00010299682617188 0.00010597705841064 Avg: 0.00010699033737183 Nothing wrong here.. [2003-02-26 08:11:50] carl at topthetable dot com count() is increasingly slow when used to count large arrays. This is using 4.3.1 (compiled from source) on a Redhat 7.2 box. The box has about 80Mb free, so it's not a paging issue. It works as expected on Mac OS X running 4.3.1-dev. Looking at PHP's and Zend's source, I would expect the time taken to return the count() of an array to be similar regardless of the size of the array. Below is a script to demonstrate the problem. -- Edit this bug report at http://bugs.php.net/?id=22435&edit=1
#22435 [NEW]: count() is slow when used with large arrays
From: carl at topthetable dot com Operating system: Redhat 7.2 PHP version: 4.3.1 PHP Bug Type: Performance problem Bug description: count() is slow when used with large arrays count() is increasingly slow when used to count large arrays. This is using 4.3.1 (compiled from source) on a Redhat 7.2 box. The box has about 80Mb free, so it's not a paging issue. It works as expected on Mac OS X running 4.3.1-dev. Looking at PHP's and Zend's source, I would expect the time taken to return the count() of an array to be similar regardless of the size of the array. Below is a script to demonstrate the problem. -- Edit bug report at http://bugs.php.net/?id=22435&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22435&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22435&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22435&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22435&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22435&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22435&r=support Expected behavior: http://bugs.php.net/fix.php?id=22435&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22435&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22435&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22435&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22435&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22435&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22435&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22435&r=gnused
#22279 [Csd]: Would like tar/tar.gz/tar.bz2 files in include_path
ID: 22279
User updated by: carl at carldunham dot com
Reported By: carl at carldunham dot com
Status: Closed
Bug Type:Feature/Change Request
PHP Version: 4.3.0
New Comment:
Ah, so something like:
$libdir = "zlib://mylib.tgz/";
require("${libdir}myfile.inc.php");
would work? Is it smart enough find mylib.tgz in the
include_path?
Previous Comments:
[2003-02-18 14:24:26] [EMAIL PROTECTED]
This is not something we plan to have in the core of PHP (too much
bloat, and not as fast as regular files), but starting in PHP 4.3.0, it
is possible to implement a virtual filesystem based on a tar archive
using PHP code itself by registering your own wrapper with the streams
subsystem.
However, the performance will not be so good on some platforms. (this
will be addressed in PHP 5).
[2003-02-18 12:58:30] carl at carldunham dot com
>From a configuration management point of view, it would be
convenient to package up a library of files in a .tar file
(optionally compressed) to include in an application. Of
course, this can be done by untaring into a directory in
the include_path, but being able to skip that step is
preferred.
This would be a similar feature Java's ".jar" file
concept.
Thanks! Love PHP to death!
--
Edit this bug report at http://bugs.php.net/?id=22279&edit=1
#22279 [NEW]: Would like tar/tar.gz/tar.bz2 files in include_path
From: carl at carldunham dot com Operating system: PHP version: 4.3.0 PHP Bug Type: Feature/Change Request Bug description: Would like tar/tar.gz/tar.bz2 files in include_path >From a configuration management point of view, it would be convenient to package up a library of files in a .tar file (optionally compressed) to include in an application. Of course, this can be done by untaring into a directory in the include_path, but being able to skip that step is preferred. This would be a similar feature Java's ".jar" file concept. Thanks! Love PHP to death! -- Edit bug report at http://bugs.php.net/?id=22279&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22279&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22279&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22279&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22279&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22279&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22279&r=support Expected behavior: http://bugs.php.net/fix.php?id=22279&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22279&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22279&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22279&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22279&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22279&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22279&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22279&r=gnused
#22201 [NEW]: Array keys like "-123" are not turned into ints
From: [EMAIL PROTECTED] Operating system: SuSE 7.2 PHP version: 4.3.0 PHP Bug Type: Arrays related Bug description: Array keys like "-123" are not turned into ints A string which would evaluate to a negative integer (such as "-123") will not be turned into an integer when used as an array key. I don't recall seeing anywhere an explicit explanation of how strings are treated when used as array keys, but obviously those strings that are valid representations of non-negative integers are implicitly treated as integers, and everything else is seen as strings. I think it would make sense to extend this to _all_ valid integers, as the behavior in this example is not quite what one would expect: $arr = array(-1 => "a", 0 => "b", 1 => "c"); $arr["-1"] = "e"; $arr["0"] = "f"; $arr["1"] = "g"; print_r($arr); echo "\n"; var_dump($arr); -- Edit bug report at http://bugs.php.net/?id=22201&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22201&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22201&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22201&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22201&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22201&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22201&r=support Expected behavior: http://bugs.php.net/fix.php?id=22201&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22201&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22201&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22201&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22201&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22201&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22201&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22201&r=gnused
#20910 [NEW]: Default for AcceptPathInfo "changed"
From: [EMAIL PROTECTED] Operating system: SuSE 7.2 PHP version: 4.3.0RC2 PHP Bug Type: Apache2 related Bug description: Default for AcceptPathInfo "changed" Maybe this is more of a feature request, but here it goes: New in Apache 2 is the possibility to turn off PATH_INFO, which was always on in Apache 1. According to the Apache docs, the _default_ value for AcceptPathInfo is given by the module used to handle a script (rather than being globally on or off). For PHP the default is off rather than on, and this breaks old scripts unless AcceptPathInfo is turned on in httpd.conf. It seems reasonable to have the old behavior be the default, rather than a behavior which potentially breaks old scripts without affecting security one way or the other, and as far as I can see the default is dictated by PHP. I, of course, would know how to turn AcceptPathInfo on if I were using Apache 2, but it seems that the world is full of users who can't be bothered to read the documentation and then complain _to me_ about 404 errors. If I've missed something crucial, feel free to trout me. :-) -- Edit bug report at http://bugs.php.net/?id=20910&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20910&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20910&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20910&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20910&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20910&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20910&r=support Expected behavior: http://bugs.php.net/fix.php?id=20910&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20910&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20910&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20910&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20910&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20910&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20910&r=isapi
#20896 [NEW]: php -w hangs indefinitely at 100% CPU
From: [EMAIL PROTECTED] Operating system: SuSE 7.2 PHP version: 4.3.0RC2 PHP Bug Type: Reproducible crash Bug description: php -w hangs indefinitely at 100% CPU Not quite a crash, but I found no better category (time to add one for the CLI SAPI?) A simple php -w filename.php will on my system output the things it should, but then hang forever at full CPU consumption. [PHP Modules] ctype gd mysql overload pcre pgsql posix session standard tokenizer xml zlib -- Edit bug report at http://bugs.php.net/?id=20896&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20896&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20896&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20896&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20896&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20896&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20896&r=support Expected behavior: http://bugs.php.net/fix.php?id=20896&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20896&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20896&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20896&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20896&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20896&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20896&r=isapi
#20797 [NEW]: 4k text limitation can be adjusted by INI_SET
From: [EMAIL PROTECTED]
Operating system: Windows NT 4.0 build 1381
PHP version: 4.2.2
PHP Bug Type: MSSQL related
Bug description: 4k text limitation can be adjusted by INI_SET
To adjust the 4k limitation of TEXT fields, I changed the TEXTSIZE and
TEXTLIMIT value of MSSQL (SET TEXTSIZE xxx) to a very high value to
prevent interference. This works properly.
Adjusting the "mssql.textlimit" and "mssql.textsize" values in php.ini
would allow larger than 4k results to be returned. This seems also fine.
However, changing this limit at run time ("ini_set("mssql.textlimit",
12000); ini_set("mssql.textsize", 12000);", 12000 (int) or "12000" string,
not making a difference) would have no impact on the selected result.
PHPINFO() shows the new adjusted value but the result would still be
limited to the value set in the PHP.INI file.
Also, "-1" (as suggested in the INI_SET function description page) seems
to limit to 4k too.
Server API: ISAPI
MSSQL Library version: 7.0
More information can be supplied if requested.
--
Edit bug report at http://bugs.php.net/?id=20797&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20797&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20797&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20797&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20797&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20797&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20797&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20797&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20797&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20797&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20797&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20797&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20797&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20797&r=isapi
Bug #16682 Updated: strange infinite loop problem where no infinite loop exists
ID: 16682 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Mac OS X PHP Version: 4.2.0 New Comment: My bad - It was a problem with the auto_prepend_file that someone stealthly added to my config, sorry about that! Previous Comments: [2002-04-18 10:50:35] [EMAIL PROTECTED] The problem is that the below script entered an infinite loop, only stopping when the when the time_limit kicks in. It's problem is caused by this script It doesn't happen on 4.1.1 CLI version, and unfortunately, I don't have access to any other versions at the moment. This is my configure line : './configure' '--with-mysql' '--with-gd=/usr/local' '-- with-png-dir=/sw' '--with-jpeg-dir=/sw' '--with-apxs' '-- with-zlib-dir=/sw' '--with-freetype-dir=/sw' '--with-curl=/ sw' '--with-t1lib=/usr/local' '--enable-ftp' '--enable- mbstring' '--enable-mbstr-enc-trans' '--with-xml' -- Edit this bug report at http://bugs.php.net/?id=16682&edit=1
Bug #16682: strange infinite loop problem where no infinite loop exists
From: [EMAIL PROTECTED] Operating system: Mac OS X PHP version: 4.2.0 PHP Bug Type: Unknown/Other Function Bug description: strange infinite loop problem where no infinite loop exists The problem is that the below script entered an infinite loop, only stopping when the when the time_limit kicks in. It's problem is caused by this script It doesn't happen on 4.1.1 CLI version, and unfortunately, I don't have access to any other versions at the moment. This is my configure line : './configure' '--with-mysql' '--with-gd=/usr/local' '-- with-png-dir=/sw' '--with-jpeg-dir=/sw' '--with-apxs' '-- with-zlib-dir=/sw' '--with-freetype-dir=/sw' '--with-curl=/ sw' '--with-t1lib=/usr/local' '--enable-ftp' '--enable- mbstring' '--enable-mbstr-enc-trans' '--with-xml' -- Edit bug report at http://bugs.php.net/?id=16682&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16682&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16682&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16682&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16682&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16682&r=support Expected behavior: http://bugs.php.net/fix.php?id=16682&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16682&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16682&r=submittedtwice
Bug #16503 Updated: mail() provides \" or \' escaped characters for single and double quotes
ID: 16503 Updated by: [EMAIL PROTECTED] -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Mail related Operating System: linux PHP Version: 4.1.2 New Comment: mail() improperly escapes single and double quotes. For example: ' appears as \' (as when an apostrophe is in the email text, like" person's automobile" shows up as "person\'s automobile". The email sent contains the escaped character with the \ in front of it instead Previous Comments: [2002-04-08 23:44:47] [EMAIL PROTECTED] mail() improperly escapes single and double quotes. For example: ' appears as \' (as when an apostrophe is in the email text, like" person's automobile" shows up as "person\'s automobile". The email sent contains the escaped character with the \ in front of it instead of sending the character properly. -- Edit this bug report at http://bugs.php.net/?id=16503&edit=1
Bug #16146: array_search always skips first element of array
From: [EMAIL PROTECTED]
Operating system: Solaris
PHP version: 4.0.6
PHP Bug Type: Arrays related
Bug description: array_search always skips first element of array
I think i've discovered a problem with array_search. If I have an array,
say
$arr = Array("one","two","a");
then I try
$retVal = array_search("one",$arr);
it will return false, however the other two elements are fine.
It seems array_search just ignores the first element in the array, I can
search the rest of the array fine, just not the first element. If I put
another item at the start I can find "one" fine.
in_array works fine, it's just array_search that fails
--
Edit bug report at http://bugs.php.net/?id=16146&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16146&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16146&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16146&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16146&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16146&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16146&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16146&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16146&r=submittedtwice
