[PHP-DEV] Bug #13521: session.save_handler = files still allows session_set_save_handler to overrid

2001-10-02 Thread merrill 

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.6
PHP Bug Type: Session related
Bug description:  session.save_handler = files still allows session_set_save_handler 
to overrid

'./configure' '--prefix=/var/php' '--with-config-file-path=/var/php'
'--enable-track-vars'
   '--with-apxs=/var/apache/bin/apxs'
'--with-ftp' '--with-xml'
   '--with-mcrypt=/var/libmcrypt-2.4.15'
'--enable-sigchild'
  
'--with-oci8=/u01/app/oracle/product/8.1.7'
'--with-pgsql=/var/postgresql-7.1.3'
   '--with-mysql=/var/mysql-3.23.41'


We use sessions stored in the database, and so we have this code in our
auto_prepend_file:

   include_once(session.inc);
   session_start();

session.inc defines functions sessionOpen, sessionClose, sessionRead,
sessionWrite, sessionDestroy, sessionGC, and at the very end of the php
code in that file, it does this call:

session_set_save_handler(
sessionOpen,
sessionClose,
sessionRead,
sessionWrite,
sessionDestroy,
sessionGC);

We wanted to change sessions from being saved in the database to being
saved in files, and noticed today that even when we set
session.save_handler = files in php.ini, the above call to
session_set_save_handler seems to still take effect and force sessions to
be stored in the database.  Here's a quote from the
set_session_save_handler documentation:

   Note: You must set the configuration option
session.save_handler to user in your php.ini file for
   session_set_save_handler() to take effect.


Is this a bug in PHP 4.0.6?

Thanks.

Hardy Merrill
Mission Critical Linux, Inc.
http://www.missioncriticallinux.com
-- 
Edit bug report at: http://bugs.php.net/?id=13521edit=1


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13521 Updated: session.save_handler = files still allows session_set_save_handler to overrid

2001-10-02 Thread merrill 

ID: 13521
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Old Operating System: 
Operating System: Redhat 6.1 Linux
PHP Version: 4.0.6
New Comment:

First update didn't save the OS - it's Redhat 6.1 Linux.

Previous Comments:


[2001-10-02 16:48:52] [EMAIL PROTECTED]

'./configure' '--prefix=/var/php' '--with-config-file-path=/var/php' 
'--enable-track-vars'
   '--with-apxs=/var/apache/bin/apxs' '--with-ftp' 
'--with-xml'
   '--with-mcrypt=/var/libmcrypt-2.4.15' 
'--enable-sigchild'
   '--with-oci8=/u01/app/oracle/product/8.1.7' 
'--with-pgsql=/var/postgresql-7.1.3'
   '--with-mysql=/var/mysql-3.23.41'


We use sessions stored in the database, and so we have this code in our 
auto_prepend_file:

   include_once(session.inc);
   session_start();

session.inc defines functions sessionOpen, sessionClose, sessionRead, sessionWrite, 
sessionDestroy, sessionGC, and at the very end of the php code in that file, it does 
this call:

session_set_save_handler(
sessionOpen,
sessionClose,
sessionRead,
sessionWrite,
sessionDestroy,
sessionGC);

We wanted to change sessions from being saved in the database to being saved in files, 
and noticed today that even when we set session.save_handler = files in php.ini, the 
above call to session_set_save_handler seems to still take effect and force sessions 
to be stored in the database.  Here's a quote from the set_session_save_handler 
documentation:

   Note: You must set the configuration option 
session.save_handler to user in your php.ini file for
   session_set_save_handler() to take effect. 

Is this a bug in PHP 4.0.6?

Thanks.

Hardy Merrill
Mission Critical Linux, Inc.
http://www.missioncriticallinux.com





Edit this bug report at http://bugs.php.net/?id=13521edit=1


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13202: HEAD request problem when use ob_start and ob_end_flush

2001-09-07 Thread merrill 

From: [EMAIL PROTECTED]
Operating system: Redhat Linux 6.1
PHP version:  4.0.4pl1
PHP Bug Type: Output Control
Bug description:  HEAD request problem when use ob_start and ob_end_flush

Software:

   Apache/1.3.19 (Unix) PHP/4.0.4pl1 mod_ssl/2.8.2 OpenSSL/0.9.6

and PHP is built as a loadable module for Apache.

'./configure' '--prefix=/var/php' '--with-config-file-path=/var/php'
'--enable-track-vars'
'--with-apxs=/var/apache/bin/apxs'
'--with-ftp' '--with-xml'
'--with-mcrypt=/var/libmcrypt'
'--enable-sigchild'
   
'--with-oci8=/u01/app/oracle/product/8.1.7'
'--with-pgsql=/var/postgresql'
'--with-mysql=/var/mysql'

HEAD requests to PHP pages that have calls to ob_start() and
ob_end_flush() do not work properly.

index.php - *without* ob_start() / ob_end_flush()
-
?
phpinfo();
?


Here's the response from a HEAD request to that index.php:
--
HTTP/1.1 200 OK
Date: Fri, 07 Sep 2001 21:11:00 GMT
Server: Apache/1.3.19 (Unix) PHP/4.0.4pl1 mod_ssl/2.8.2 OpenSSL/0.9.6
X-Powered-By: PHP/4.0.4pl1
Connection: close
Content-Type: text/html

Connection closed by foreign host.

===

index.php - *with* ob_start() / ob_end_flush()
--
?
ob_start();
phpinfo();
ob_end_flush();
?


Here's the response from a HEAD request to that index.php:
--

Connection closed by foreign host.



Is this a bug with PHP 4.0.4pl1?
-- 
Edit bug report at: http://bugs.php.net/?id=13202edit=1


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9876: OCIPLogon flaky after restart Oracle

2001-03-20 Thread merrill 

From: [EMAIL PROTECTED]
Operating system: Redhat 6.1 Linux
PHP version:  4.0.4pl1
PHP Bug Type: OCI8 related
Bug description:  OCIPLogon flaky after restart Oracle

./configure' '--prefix=/var/php' '--with-config-file-path=/var/php' 
'--enable-track-vars'
  '--enable-sigchild' 
'--with-apache=../apache_1.3.14' '--with-ftp' '--with-xml'
  '--with-mcrypt=/var/libmcrypt' 
'--with-pgsql=/var/postgresql'
  '--with-oci8=/u01/app/oracle/product/8.1.6' 
'--with-mysql=/var/mysql'

When using OCIPLogon for persistent connections, I'm noticing that after restarting 
Oracle, that my PHP application starts getting Oracle errors(ORA-03113 and ORA-03114). 
 This can be fixed by restarting the webserver after restarting Oracle.  I also notice 
that changing my Oracle connections from OCIPLogon to OCILogon fixes the problem - 
after making that change I get no errors after restarting Oracle, and I *don't* have 
to restart the webserver.

The OCI8 interface must have a bug, right?  I shouldn't have to restart the webserver 
after restarting Oracle just because I'm using persistent connections, should I?


-- 
Edit Bug report at: http://bugs.php.net/?id=9876edit=1



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9510: OCIError function with no params does *NOT* return the last error

2001-03-01 Thread merrill 

From: [EMAIL PROTECTED]
Operating system: Redhat 6.1 Linux
PHP version:  4.0.4pl1
PHP Bug Type: OCI8 related
Bug description:  OCIError function with no params does *NOT* return the "last" error

PHP 4.0.4pl1

'./configure' '--prefix=/var/php' '--with-config-file-path=/var/php' 
'--enable-track-vars'  '--enable-sigchild' '--with-apache=../apache_1.3.14' 
'--with-ftp'
   '--with-mcrypt=/var/libmcrypt' 
'--with-pgsql=/var/postgresql'   
'--with-oci8=/u01/app/oracle/product/8.1.6' '--with-mysql=/var/mysql'

According to the OCIError documentation, OCIError invoked with no parameters is 
supposed to return the *last* error.  But here's an example where OCIError invoked 
with no parameters returns *no* error.  This should be fixed to return the last error.

Given this SELECT

   select abc from customer


with a column that does NOT exist("abc") in table "customer", the OCIExecute returns 
"false", but then OCIError() invoked with no parameters is supposed to return the 
"last" error, but returns no error.  In this case, OCIError($cursor) invoked with the 
$cursor parameter *does* return the proper error:

  ORA-00904: invalid column name




-- 
Edit Bug report at: http://bugs.php.net/?id=9510edit=1



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]