#27306 [NEW]: php script not parsed by apache

2004-02-18 Thread ngcheongmeng at pacific dot net dot sg
From: ngcheongmeng at pacific dot net dot sg
Operating system: RedHat 7.3
PHP version:  4.3.4
PHP Bug Type: *General Issues
Bug description:  php script not parsed by apache

Description:

Sometime when accessing a php page, the browser just show the raw php
script. When click on refresh, the php script get executed and display the
correct output. This seem to be an intermittent problem. It occurs more
frequently if I restart the apache daemon by doing a apachectl graceful
or access with a new browser session. 

My php is compiled as DSO module in apache-1.3.29.



I noticed there is a similar bug reported by bug#7147 for php 4.0.3. Not
sure if it is the same bug encounter by me.



pls help. thx

Reproduce code:
---
Access the php page by a new browser session.

Or

restart apache by apachectl graceful




-- 
Edit bug report at http://bugs.php.net/?id=27306edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27306r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27306r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27306r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27306r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27306r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27306r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27306r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27306r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27306r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27306r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27306r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27306r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27306r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27306r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27306r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27306r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27306r=float


#27292 [Opn-Bgs]: Page time out

2004-02-18 Thread sniper
 ID:   27292
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jforgey at wt dot net
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: win 2k
 PHP Version:  4.3.4
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

You must be doing something wrong, I can not reproduce this with
properly configured Apache2 + PHP under Windows.




Previous Comments:


[2004-02-18 00:17:41] jforgey at wt dot net

No safe mode not on



[2004-02-18 00:16:25] jforgey at wt dot net

I'm also using Apache v2



[2004-02-17 16:18:10] [EMAIL PROTECTED]

Do you happen to have safe_mode on? (can not reproduce, timeout works
as expected for me)





[2004-02-17 14:06:58] jforgey at wt dot net

Description:

When you set the time out using set_time_limit and the page times
out. The page will report the default time limit setting in the php.ini
file and not the time limit set from the php page

Reproduce code:
---
set_time_limit(15 * 60); //timeout 15 mins

Expected result:

page time out of 15 mins

Actual result:
--
page time out of 30 sec





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


#27306 [Opn-Bgs]: php script not parsed by apache

2004-02-18 Thread sniper
 ID:   27306
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ngcheongmeng at pacific dot net dot sg
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: RedHat 7.3
 PHP Version:  4.3.4
 New Comment:

Already fixed. Please don't submit bug reports without searching the
bug database for existing reports!


Previous Comments:


[2004-02-18 02:55:48] ngcheongmeng at pacific dot net dot sg

Description:

Sometime when accessing a php page, the browser just show the raw php
script. When click on refresh, the php script get executed and display
the correct output. This seem to be an intermittent problem. It occurs
more frequently if I restart the apache daemon by doing a apachectl
graceful or access with a new browser session. 

My php is compiled as DSO module in apache-1.3.29.



I noticed there is a similar bug reported by bug#7147 for php 4.0.3.
Not sure if it is the same bug encounter by me.



pls help. thx

Reproduce code:
---
Access the php page by a new browser session.

Or

restart apache by apachectl graceful








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


#26873 [Fbk-NoF]: Constructors have problems with parameters when result of new isn't assigned

2004-02-18 Thread sniper
 ID:   26873
 Updated by:   [EMAIL PROTECTED]
 Reported By:  richard at garandnet dot net
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Class/Object related
 Operating System: *
 PHP Version:  5CVS, 4CVS
 New Comment:

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.




Previous Comments:


[2004-02-13 10:16:19] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip





[2004-02-08 11:49:33] [EMAIL PROTECTED]

btw. What's the idea with doing this anyway?





[2004-01-11 19:13:58] [EMAIL PROTECTED]

Output with latest PHP 5 (HEAD) cvs:



Array

(

[name] = c

)

/usr/src/web/php/php5/Zend/zend_API.c(721) :  Freeing 0x40E4ACBC (32
bytes), script=t.php

/usr/src/web/php/php5/Zend/zend_hash.c(157) : Actual location (location
was relayed)

/usr/src/web/php/php5/Zend/zend_execute.c(3095) :  Freeing 0x40E489CC
(44 bytes), script=t.php

/usr/src/web/php/php5/Zend/zend_API.c(720) : Actual location (location
was relayed)

/usr/src/web/php/php5/Zend/zend_execute.c(3094) :  Freeing 0x40E482C4
(16 bytes), script=t.php

/usr/src/web/php/php5/Zend/zend_objects.c(88) :  Freeing 0x40E4823C (12
bytes), script=t.php

=== Total 4 memory leaks detected ===



Output with latest PHP 4_3 checkout:



Array

(

[name] = c

)

/usr/src/web/php/php4/Zend/zend_API.c(594) :  Freeing 0x08644A24 (44
bytes), script=t.php

/usr/src/web/php/php4/Zend/zend_API.c(582) : Actual location (location
was relayed)

/usr/src/web/php/php4/Zend/zend_hash.c(188) :  Freeing 0x0864EC4C (32
bytes), script=t.php

/usr/src/web/php/php4/Zend/zend_execute.c(1979) :  Freeing 0x0864E4DC
(12 bytes), script=t.php





[2004-01-11 15:20:16] richard at garandnet dot net

Description:

 

Reproduce code:
---
class B

{

  function B($name) {

$this-name = $name;

  }

}

class A

{

  function A($b) {

print_r(get_object_vars($b));

  }

}



new A(new B(c));

$bug = new A(new B(c));

Expected result:

Output: 

Array ( [name] = c ) 

Array ( [name] = c ) 

Actual result:
--
Output: 

Array ( [name] = b Object ( [name] = *RECURSION* ) ) 

Array ( [name] = c ) 





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


#14776 [Com]: httpd crashes with 4.1.1 (and 4.1.0) when safe-mode=on and header();

2004-02-18 Thread remove at my dot email
 ID:   14776
 Comment by:   remove at my dot email
 Reported By:  fabio at isec dot com dot br
 Status:   Closed
 Bug Type: Reproducible crash
 Operating System: FreeBSD 4.4-stable
 PHP Version:  4.1.1
 New Comment:

[EMAIL PROTECTED]


Previous Comments:


[2004-02-18 04:07:04] remove at my dot email

ID: 14776

Comment by: [EMAIL PROTECTED]

Old Reported By: [EMAIL PROTECTED]

Reported By: [EMAIL PROTECTED]

Status: Feedback

Bug Type: Reproducible crash

Operating System: FreeBSD 4.4-stable

PHP Version: 4.1.1

New Comment:



[2002-01-14 22:10:35] [EMAIL PROTECTED]

User reported it works. Closed



[2002-01-14 18:55:06] jj at lap dot ttu dot ee

Ok, found it allready.

and this patch really works!

thanx



[2002-01-14 18:33:43] jj at lap dot ttu dot ee

which files were modified?

how can i get only these files from anonymous cvs?



thanx



[2002-01-14 08:46:24] [EMAIL PROTECTED]

I just fixed it in CVS

(atleast I cannot crash it here anymore)



Please check with latest CVS version.



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/14776

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


#27308 [NEW]: Include Paths

2004-02-18 Thread php at richard-fila dot co dot uk
From: php at richard-fila dot co dot uk
Operating system: Windows  Linux
PHP version:  Irrelevant
PHP Bug Type: *Directory/Filesystem functions
Bug description:  Include Paths

Description:

When including a file the handling of paths differs between linux and
windows.



When including a file from a file which has already been included the
second level include paths are different.  Windows recalculates the ./
path for each included script while linux just uses the ./ path from the
first script accessed.  This means relative paths cannot be used.



Obviously the windows method is the correct one.


-- 
Edit bug report at http://bugs.php.net/?id=27308edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27308r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27308r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27308r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27308r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27308r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27308r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27308r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27308r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27308r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27308r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27308r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27308r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27308r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27308r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27308r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27308r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27308r=float


#27309 [NEW]: unable to go to parent directory with require_once !

2004-02-18 Thread vexal at ifrance dot com
From: vexal at ifrance dot com
Operating system: Win2k
PHP version:  5.0.0b4 (beta4)
PHP Bug Type: Compile Failure
Bug description:  unable to go to parent directory with require_once !

Description:

Works with php5b3 but not php5b4.

With the require_once statement, it's impossible to go to a parent
directory.

a fatal error occurs while the compilation.

Reproduce code:
---
file test1.php in directory test1/ :



?php

require_once ../test2.php;

echo $hello;

?



file test2.php in the parent directory :



?php

$hello=Hello World !;

?

Expected result:

compilation ok and print Hello World !

Actual result:
--
A fatal error occurs while compilation because it is unable to locate
test2.php

-- 
Edit bug report at http://bugs.php.net/?id=27309edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27309r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27309r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27309r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27309r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27309r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27309r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27309r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27309r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27309r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27309r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27309r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27309r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27309r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27309r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27309r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27309r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27309r=float


#27310 [NEW]: preg_replace regexp causes PHP to die

2004-02-18 Thread paul at pscs dot co dot uk
From: paul at pscs dot co dot uk
Operating system: Win32 (Windows XP)
PHP version:  4.3.5RC3
PHP Bug Type: Reproducible crash
Bug description:  preg_replace regexp causes PHP to die

Description:

It looks as if when PHP is doing preg_replace and there are a lot of ()
values, then it just dies



With my example code, it'll die when doing preg_replace



I've tried a few values of $regexp on line 2



/(.|\n)*/  - it dies

/(.)*/ - it dies

/.*/   - it works fine



If the $test string is 1844 characters long it works fine, if it's 1845
characters long it dies.



It doesn't matter whether the string actually matches or not, it's the
number of characters it's trying to match.



The problem doesn't seem to happen with preg_match





Reproduce code:
---
?php

$regexp = /(.|\n)*/;

$stringlength = 1845;



echo test start \n;

$test = '' . str_repeat('x', $stringlength - 1);



$test = preg_replace($regexp,,$test);

echo test done\n;

?



Expected result:

test start

test done

Actual result:
--
nothing

-- 
Edit bug report at http://bugs.php.net/?id=27310edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27310r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27310r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27310r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27310r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27310r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27310r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27310r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27310r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27310r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27310r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27310r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27310r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27310r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27310r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27310r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27310r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27310r=float


#27311 [NEW]: array values are ignored wheb beginning with a 0 number

2004-02-18 Thread MichaelGlazer at quickenloans dot com
From: MichaelGlazer at quickenloans dot com
Operating system: winxp
PHP version:  4.3.4
PHP Bug Type: Scripting Engine problem
Bug description:  array values are ignored wheb beginning with a 0 number

Description:

Creating an array with hardcoded number values beginning with a number 0
does not save anything beyond the 0.



This is when done outside of any quotes, single or double.



It works fine when quotes are added to these numbers.

Reproduce code:
---
$a=array(

1980,

0891

);



print_r($a);

Expected result:

Array

(

[0] = 1980

[1] = 0891

)





Actual result:
--
Array

(

[0] = 1980

[1] = 0

)





-- 
Edit bug report at http://bugs.php.net/?id=27311edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27311r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27311r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27311r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27311r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27311r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27311r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27311r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27311r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27311r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27311r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27311r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27311r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27311r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27311r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27311r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27311r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27311r=float


#27309 [Fbk-Csd]: unable to go to parent directory with require_once !

2004-02-18 Thread vexal at ifrance dot com
 ID:   27309
 User updated by:  vexal at ifrance dot com
 Reported By:  vexal at ifrance dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: Zend Engine 2 problem
 Operating System: win32 only
 PHP Version:  5.0.0b4 (beta4)
 New Comment:

thank you, it's ok now :)


Previous Comments:


[2004-02-18 11:50:19] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip





[2004-02-18 06:14:26] vexal at ifrance dot com

Description:

Works with php5b3 but not php5b4.

With the require_once statement, it's impossible to go to a parent
directory.

a fatal error occurs while the compilation.

Reproduce code:
---
file test1.php in directory test1/ :



?php

require_once ../test2.php;

echo $hello;

?



file test2.php in the parent directory :



?php

$hello=Hello World !;

?

Expected result:

compilation ok and print Hello World !

Actual result:
--
A fatal error occurs while compilation because it is unable to locate
test2.php





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


#27312 [NEW]: mod_php crashes on enabling any extension php_*.dll

2004-02-18 Thread php at koteroff dot ru
From: php at koteroff dot ru
Operating system: Windows 98
PHP version:  5.0.0b4 (beta4)
PHP Bug Type: Reproducible crash
Bug description:  mod_php crashes on enabling any extension php_*.dll

Description:

When I try to enable any extension (no matter, which - for example,
php_bz2.dll) in php.ini, Apache 1.3.27 crashes just after mod_php loaded.



File monitor (filemon) from http://sysinternals.com says that there is NO
file not found events, and php_bz2.dll is found and loaded correctly.
Seems startup code of php5apache.dll finished correctly, and then Apache
chashes.



Php-cgi.exe works fine.



Extension_dir, php5ts.dll - all these OK. I have some expierence
installing lot of PHP versions.



If noone extension is uncommented and loaded, mod_php works fine.



Seeems there is a bug in php5apache.dll?

Reproduce code:
---
extension=php_bz2.dll

Expected result:

mod_php loaded

Actual result:
--
Apache crash (GPF).

-- 
Edit bug report at http://bugs.php.net/?id=27312edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27312r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27312r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27312r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27312r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27312r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27312r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27312r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27312r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27312r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27312r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27312r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27312r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27312r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27312r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27312r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27312r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27312r=float


#27312 [Opn-Fbk]: mod_php crashes on enabling any extension php_*.dll

2004-02-18 Thread derick
 ID:   27312
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at koteroff dot ru
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Windows 98
 PHP Version:  5.0.0b4 (beta4)
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip


Previous Comments:


[2004-02-18 13:22:03] php at koteroff dot ru

Description:

When I try to enable any extension (no matter, which - for example,
php_bz2.dll) in php.ini, Apache 1.3.27 crashes just after mod_php
loaded.



File monitor (filemon) from http://sysinternals.com says that there is
NO file not found events, and php_bz2.dll is found and loaded
correctly. Seems startup code of php5apache.dll finished correctly, and
then Apache chashes.



Php-cgi.exe works fine.



Extension_dir, php5ts.dll - all these OK. I have some expierence
installing lot of PHP versions.



If noone extension is uncommented and loaded, mod_php works fine.



Seeems there is a bug in php5apache.dll?

Reproduce code:
---
extension=php_bz2.dll

Expected result:

mod_php loaded

Actual result:
--
Apache crash (GPF).





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


#27313 [NEW]: ./configure[66644]: yes: not found.

2004-02-18 Thread admin at iut-info dot ens dot univ-reims dot fr
From: admin at iut-info dot ens dot univ-reims dot fr
Operating system: HP-UX 11.11
PHP version:  5CVS-2004-02-18 (dev)
PHP Bug Type: *Compile Issues
Bug description:  ./configure[66644]: yes:  not found.

Description:

A very old problem whith the configure script.



When running ./configure \

--prefix=/opt/APACHE/php\

--with-oci8 \

--with-apache=../apache_1.3.29  \

--with-gd   \

--with-pdflib=/opt/pdflib   \

--with-jpeg-dir \

--with-png-dir  \

--with-tiff-dir \

--with-zlib \

--with-bz2  \

--enable-sigchild   \

--with-mysql=/opt/mysql \

--with-pgsql=/opt/pgsql \

--without-sqlite\

--with-tsrm-pthreads\

--with-dom  \

--with-libxml   \

--with-xsl  \

--enable-ftp\

--with-snmp=/opt/snmp   \

--enable-sockets



-

checking for PDFlib support... yes

checking for the location of libtiff... yes

./configure[66644]: yes:  not found.

checking for jpeg_read_header in -ljpeg... (cached) yes

./configure[66771]: yes:  not found.

./configure[66878]: yes:  not found.

checking for png_create_info_struct in -lpng... yes

./configure[67005]: yes:  not found.

./configure[67112]: yes:  not found.

checking for TIFFOpen in -ltiff... yes

./configure[67239]: yes:  not found.

checking for the location of zlib... /usr/local

checking for PDF_show_boxed in -lpdf... 

-



PDFLib is version 5.0.2



Without --with-jpeg-dir, --with-png-dir and --with-tiff-dir   
 options, error occurs only on line 66878 and 67005



I'm used to continue without any problem.



Cordialy.


-- 
Edit bug report at http://bugs.php.net/?id=27313edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27313r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27313r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27313r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27313r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27313r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27313r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27313r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27313r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27313r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27313r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27313r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27313r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27313r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27313r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27313r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27313r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27313r=float


#27313 [Opn-Bgs]: ./configure[66644]: yes: not found.

2004-02-18 Thread sniper
 ID:   27313
 Updated by:   [EMAIL PROTECTED]
 Reported By:  admin at iut-info dot ens dot univ-reims dot fr
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: HP-UX 11.11
 PHP Version:  5CVS-2004-02-18 (dev)
 New Comment:

When you abuse the configure of course you get problems too.

There is no bug here, pass the correct install prefix to the
--with-*-dir options.




Previous Comments:


[2004-02-18 13:28:50] admin at iut-info dot ens dot univ-reims dot fr

Description:

A very old problem whith the configure script.



When running ./configure \

--prefix=/opt/APACHE/php\

--with-oci8 \

--with-apache=../apache_1.3.29  \

--with-gd   \

--with-pdflib=/opt/pdflib   \

--with-jpeg-dir \

--with-png-dir  \

--with-tiff-dir \

--with-zlib \

--with-bz2  \

--enable-sigchild   \

--with-mysql=/opt/mysql \

--with-pgsql=/opt/pgsql \

--without-sqlite\

--with-tsrm-pthreads\

--with-dom  \

--with-libxml   \

--with-xsl  \

--enable-ftp\

--with-snmp=/opt/snmp   \

--enable-sockets



-

checking for PDFlib support... yes

checking for the location of libtiff... yes

./configure[66644]: yes:  not found.

checking for jpeg_read_header in -ljpeg... (cached) yes

./configure[66771]: yes:  not found.

./configure[66878]: yes:  not found.

checking for png_create_info_struct in -lpng... yes

./configure[67005]: yes:  not found.

./configure[67112]: yes:  not found.

checking for TIFFOpen in -ltiff... yes

./configure[67239]: yes:  not found.

checking for the location of zlib... /usr/local

checking for PDF_show_boxed in -lpdf... 

-



PDFLib is version 5.0.2



Without --with-jpeg-dir, --with-png-dir and --with-tiff-dir
options, error occurs only on line 66878 and 67005



I'm used to continue without any problem.



Cordialy.






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


#27291 [Com]: get_browser matches browscap.ini patterns incorrectly

2004-02-18 Thread php_bug_27291 at garykeith dot com
 ID:   27291
 Comment by:   php_bug_27291 at garykeith dot com
 Reported By:  php-bug-NOSPAM-2004 at ryandesign dot com
 Status:   Closed
 Bug Type: *General Issues
 Operating System: Mac OS X; FreeBSD; RedHet Linux
 PHP Version:  4.3.4
 New Comment:

Respectfully, my latest browscap.ini does not detect all arbitrary
versions of Safari. I'm not sure how you arrived at that conclusion.



I do know that I receive e-mails nearly every day about this issue so
there is obviously a problem somewhere.



I don't know who is working on the code for get_browser() these days
but I wish they would contact me so we could come to some sort of
understanding about how to properly parse my file the way browscap.dll
does. I am growing very weary of my files and efforts taking the blame
for the non-stop stream of bugs that emanate from get_browser().



Thanks,

~gary.


Previous Comments:


[2004-02-17 18:08:59] php-bug-NOSPAM-2004 at ryandesign dot com

I downloaded and compiled 4.3.5RC3 and the issue 

remains. I am not versed in CVS, and I was unable to 

compile the version I got from the CVS server. It 

complained about requiring libxml, which I did not 

request. I did not see any changes in the browscap.c 

file on the CVS server (when viewed through its web 

interface) which would account for any change in its 

behavior. I will test again with 4.3.5 final when it is 

released.



Perhaps a better UA string to test would be this...



Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) 

UnknownWebKit/555 (KHTML, like Gecko) UnknownBrowser/444



...since the 2/15/2004 browscap.ini from garykeith.com 

does now detect arbitrary Safari versions. The above UA, 

however, still is identified as a Website Stripper, 

though it should be identified as a Default Browser.



[2004-02-17 16:12:58] [EMAIL PROTECTED]

Using latest stable CVS snapshot does match with Default Browser..





[2004-02-17 14:01:22] php-bug-NOSPAM-2004 at ryandesign dot com

Description:

PHP's get_browser() function does not correctly use the 

patterns in the browscap.ini file, resulting in 

occasional incorrect matches. This occurred, for 

example, when Apple released Safari 1.2, and when 

OmniGroup released OmniWeb 5.0b1. These two browsers 

were then incorrectly identified as crawlers / robots, 

instead of being recognized as normal browsers.



Instead of matching the last rule in the file (which has 

the browscap pattern * which PHP translates into the 

regular expression .*), it matches the rule for 

Website Strippers (which has the browscap pattern 

Mozilla/5.0 which PHP translates to the regular 

expression Mozilla/5\.0). Yes, Safari and OmniWeb have 

Mozilla/5.0 as part of their user agent string, but 

only part. Mozilla/5.0 is not the ENTIRE UA string, 

which is what the browscap pattern is intending to 

define. Had the rule been intended to match Mozilla/

5.0 at the start of the string, regardless of what 

followed, the rule would have been written Mozilla/

5.0*. But it wasn't. PHP needs to anchor the regular 

expression it generates to the beginning and end of the 

string to ensure it is matching the portion of the 

string the browscap.ini author intended it to match. The 

regular expressions PHP should have generated are 

^Mozilla/5\.0$ and ^.*$.



Here is a diff of the PHP source code file

ext/standard/browscap.c (from the version in the 4.3.4 

release) which seems to correct the problem. The 

commenting out of lines 71 to 73 in the original file 

(73 to 75 in my version) is not essential and is not 

part of the fix for this issue, but was done because 

those lines seem to me to be another inaccuracy in PHP's 

browscap.ini parsing, and their removal does not seem to 

adversely affect the functioning of get_browser(), 

although I did not extensively test against many user 

agent strings, and I do not know the reason that code 

was originally inserted.



50c50

   t = (char *) malloc(Z_STRLEN_P(pattern)*2 + 1);

---

   t = (char *) malloc(Z_STRLEN_P(pattern)*2 + 3);

52c52,54

   for (i=0, j=0; iZ_STRLEN_P(pattern); i++, j++) 

{

---

   t[0] = '^';

 

   for (i=0, j=1; iZ_STRLEN_P(pattern); i++, j++) 

{

71,73c73,75

   if (j  (t[j-1] == '.')) {

   t[j++] = '*';

   }

---

 //if (j  (t[j-1] == '.')) {

 //t[j++] = '*';

 //}

74a77,78

   t[j++] = '$';

 

Reproduce code:
---
Install the browscap.ini file available from www.garykeith.com and
modify the php.ini to use this file. Then run this:



$ua = 'Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/1999
(KHTML, like Gecko) Safari/1999';



$ua_info = (array) get_browser($ua);



print $ua;



#25876 [Com]: session_start(): Failed to initialize storage module

2004-02-18 Thread mitch at webcob dot com
 ID:   25876
 Comment by:   mitch at webcob dot com
 Reported By:  golden at riscom dot com
 Status:   Bogus
 Bug Type: Session related
 Operating System: freebsd 4.8
 PHP Version:  4.3.3
 New Comment:

I'm also running FreeBSD 4.8 - same problem.



My /tmp is on a separate partition, and has plenty of space... a
restart (even a graceful one) seems to fix the problem.



As a temp fix, I heard someone say that the sites they had using custom
session storage handlers did NOT exhibit the problem, so I think I may
try an auto-prepend file containing such an override on a server-wide
basis.



Any comment on this idea? Please copy my email.



Thanks.


Previous Comments:


[2004-02-18 11:18:59] bigrob at cox-internet dot com

I'm having the same problems. FreeBSD 4.8, php 4.3.4. 





THIS IS GETTING VERY annoying. It quit doing it for a month, then
almost to the exact day it just started up again this morning at 1AM
and hasn't stoppd. Apache 2.0.47 as well. Restarting apache seems to do
the trick for about a minute, then it starts popping up again. I've
already had 20 customers call this morning saying they cannot place
orders and they give me the error. 



I've check my apache access logs as well as the php log. 



I get this error several times:



[18-Feb-2004 10:15:39] PHP Warning:  Unknown(): A session is active.
You cannot change the session module's ini settings at this time. in
Unknown on line 0



Almost always following it is this srror:



[18-Feb-2004 10:15:51] PHP Fatal error:  session_start(): Failed to
initialize storage module. in /mydir/myfile.php3 on line 2



All that is in myfile.php3 is session_start();



These errors started happening after moving to a new sever. NO PROBLEMS
in the past, was using Apache 1.3.8 I believe and PHP 4.3.0. 



PHP People, WHAT ARE CAUSING THESE ERRORS



[2004-02-18 07:35:32] c dot i dot morris at durham dot ac dot uk

We're also getting this bug.

Apache 1.3.27

PHP 4.3.2

Solaris 8 (rather than BSD) as the OS



It happens intermittently, reloading the page _usually_ clears it. 
Different users report different things.  I've never been able to
duplicate it on my browsers (tested IE and Mozilla, no difference), a
colleague gets it occasionally, users reporting the problem to us get
it one time in three in the worst cases.



/tmp is writeable and has a huge amount of free space.



Multiple users have reported the problem to us, the minimal code sample
already reported is the only common part.  We are attempting to find if
there is anything special about the requests that trigger it, but so
far nothing - will update if we find anything.



[2004-02-10 16:45:59] bernoico at netcabo dot pt

A have this problem to, is very annoying... I made a search in google
for Fatal error: session_start(): Failed to initialize storage module
and I found millions of sites in this condition... Are there any work
around?

Thanks.



[2004-02-07 22:58:14] [EMAIL PROTECTED]

close





[2004-02-05 04:08:22] golden at riscom dot com

Open



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/25876

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


#27312 [Fbk-Csd]: mod_php crashes on enabling any extension php_*.dll

2004-02-18 Thread php at koteroff dot ru
 ID:   27312
 User updated by:  php at koteroff dot ru
 Reported By:  php at koteroff dot ru
-Status:   Feedback
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Windows 98
 PHP Version:  5.0.0b4 (beta4)
 New Comment:

Excellent, thanks.


Previous Comments:


[2004-02-18 13:26:36] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip



[2004-02-18 13:22:03] php at koteroff dot ru

Description:

When I try to enable any extension (no matter, which - for example,
php_bz2.dll) in php.ini, Apache 1.3.27 crashes just after mod_php
loaded.



File monitor (filemon) from http://sysinternals.com says that there is
NO file not found events, and php_bz2.dll is found and loaded
correctly. Seems startup code of php5apache.dll finished correctly, and
then Apache chashes.



Php-cgi.exe works fine.



Extension_dir, php5ts.dll - all these OK. I have some expierence
installing lot of PHP versions.



If noone extension is uncommented and loaded, mod_php works fine.



Seeems there is a bug in php5apache.dll?

Reproduce code:
---
extension=php_bz2.dll

Expected result:

mod_php loaded

Actual result:
--
Apache crash (GPF).





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


#26238 [Ver]: flush() doesn't work with output_buffering = 4096

2004-02-18 Thread sniper
 ID:   26238
 Updated by:   [EMAIL PROTECTED]
 Reported By:  spam at vrana dot cz
 Status:   Verified
 Bug Type: Output Control
 Operating System: *
 PHP Version:  4CVS, 5CVS
 New Comment:

Here's nice and short reproduce script:



# php -d'output_buffering=2' -r 'while(1) {echo .; flush(); sleep(1);
}'






Previous Comments:


[2003-11-17 13:14:20] scottm at spamcop dot net

Confirmed.



If you set output_buffering = 3 then it will flush them in groups of
three.



Running RH9, Apache 1.3.29 and PHP 4.3.4



[2003-11-13 08:40:59] spam at vrana dot cz

Description:

I have set output_buffering = 4096 and flush(), ob_implicit_flush(),
ob_flush() and similar functions doesn't work. This is reproducible in
PHP Apache module, in PHP-CLI and also on Linux.

Reproduce code:
---
while (true) {

echo .;

flush();

sleep(1);

}



Expected result:

. (1 second) . (1 second) ...

Actual result:
--
nothing (for output_buffering seconds)





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


#27316 [NEW]: Automatically add PHP directory to PATH

2004-02-18 Thread php at koteroff dot ru
From: php at koteroff dot ru
Operating system: Windows
PHP version:  5.0.0b4 (beta4)
PHP Bug Type: Feature/Change Request
Bug description:  Automatically add PHP directory to PATH

Description:

New PHP distribution directory structure is great. Now php.exe works
immediately after unpacking  modifying php.ini.



But with mod_php thinks are worse. To make him start I have to:

1. Set PHPRC environment variable equal to PHP5 directory path (to search
php.ini in this directory - for example, let it be z:/usr/local/php5).

2. Manually add z:/usr/local/php5 to PATH to allow PHP search for
libmysql.dll, libeay32.dll etc. while loading extensions.



It is too importunate and makes mod_php usage greatly harder than CGI
version using. That's why I ask you to add the following features:



1. By default search php.ini not only in apache directory (it's silly) and
in windows directory (it's silly twice - nothing personal: nobody wants to
trash windows folder), but at php5apache.dll directory too.

2. Also add directory in which php5apache.dll resides to PATH (possibly at
php5apache startup code).



These changes will unversalize PHP and make mod_php installation not
harder than CGI installation. (I'd like to say thet a lot of people uses
Windows-PHP in debugging purposes. That's why they have 2 or 3 different
version of PHP at the same server.)



To get current module name, we may use GetModuleFileName API call. To set
environment variable PATH GetEnvironmentVariable and
SetEnvironmentVariable may be used.



Please answer what do you thing about all of these?


-- 
Edit bug report at http://bugs.php.net/?id=27316edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27316r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27316r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27316r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27316r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27316r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27316r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27316r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27316r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27316r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27316r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27316r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27316r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27316r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27316r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27316r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27316r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27316r=float


#27308 [Opn-Bgs]: Include Paths

2004-02-18 Thread iliaa
 ID:   27308
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at richard-fila dot co dot uk
-Status:   Open
+Status:   Bogus
 Bug Type: *Directory/Filesystem functions
 Operating System: Windows  Linux
 PHP Version:  Irrelevant
 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The behavior is different for ZTS and non-zts modes. 


Previous Comments:


[2004-02-18 05:51:38] php at richard-fila dot co dot uk

Description:

When including a file the handling of paths differs between linux and
windows.



When including a file from a file which has already been included the
second level include paths are different.  Windows recalculates the ./
path for each included script while linux just uses the ./ path from
the first script accessed.  This means relative paths cannot be used.



Obviously the windows method is the correct one.






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


#27221 [Com]: $_POST superglobal variable not populated after posting a form

2004-02-18 Thread steve dot carrico at louisville dot edu
 ID:   27221
 Comment by:   steve dot carrico at louisville dot edu
 Reported By:  patrick at studioemma dot be
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: Redhat 7.3
 PHP Version:  4.3.4
 New Comment:

I don't beleive this is a PHP bug.  We started receiving similar
problem reports at the university I work for after the latest Internet
Explorer security update was released.  I came across the following
Microsoft Knowledge Base article yesterday and the software update
linked under the Resolution section appears to fix the problem:



http://support.microsoft.com/default.aspx?scid=kb;en-us;831167


Previous Comments:


[2004-02-12 10:02:39] [EMAIL PROTECTED]

Can not reproduce using latest CVS (or even with 4.3.4)





[2004-02-12 05:10:24] patrick at studioemma dot be

I will wait for the definite release. I can however allready add these
comments:



- only occurs on SSL

- occurs when some fields (no reserved words as names) have spaces,
numeric values, and perhaps others.



In the meantime I moved to just HTTP instead of HTTPS



[2004-02-11 15:02:01] [EMAIL PROTECTED]

Just try the snapshot first.





[2004-02-11 14:51:49] patrick at studioemma dot be

my httpd.conf only mentions:



AddType application/x-httpd-php .php4 .php3 .phtml .php

AddType application/x-httpd-php-source .phps



However I have found a key to the origin: apparently the values I enter
in the form influence the problem. I have been able to reproduce but
cannot figure out any logic. I have to mention I'm only using a-zA-Z
and - signs..

it's like black magic...



I have not yet installed the snapshot, will definitely await final
release. I have to mention as well that I just upgraded to 4.3.4 from
4.3.2 where the problem occured as well.



[2004-02-11 14:04:52] [EMAIL PROTECTED]

Obviously you are not using Apache2, so



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





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/27221

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


#26238 [Com]: flush() doesn't work with output_buffering = 4096

2004-02-18 Thread scottmacvicar at ntlworld dot com
 ID:   26238
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  spam at vrana dot cz
 Status:   Verified
 Bug Type: Output Control
 Operating System: *
 PHP Version:  4CVS, 5CVS
 New Comment:

Setting output_buffering to a value causes it to create an ouput buffer
on startup using the default output handler. You can see this using
print_r(ob_get_status()); within the script.



ob_flush() should be used in this case rather than flush() since the
latter only calls the backends flush method. So i believe this bug is
bogus, though it could be a documentation problem.


Previous Comments:


[2004-02-18 17:19:31] [EMAIL PROTECTED]

Here's nice and short reproduce script:



# php -d'output_buffering=2' -r 'while(1) {echo .; flush(); sleep(1);
}'







[2003-11-17 13:14:20] scottm at spamcop dot net

Confirmed.



If you set output_buffering = 3 then it will flush them in groups of
three.



Running RH9, Apache 1.3.29 and PHP 4.3.4



[2003-11-13 08:40:59] spam at vrana dot cz

Description:

I have set output_buffering = 4096 and flush(), ob_implicit_flush(),
ob_flush() and similar functions doesn't work. This is reproducible in
PHP Apache module, in PHP-CLI and also on Linux.

Reproduce code:
---
while (true) {

echo .;

flush();

sleep(1);

}



Expected result:

. (1 second) . (1 second) ...

Actual result:
--
nothing (for output_buffering seconds)





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


#27316 [Opn-Fbk]: Automatically add PHP directory to PATH

2004-02-18 Thread edink
 ID:   27316
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at koteroff dot ru
-Status:   Open
+Status:   Feedback
 Bug Type: Feature/Change Request
 Operating System: Windows
 PHP Version:  5.0.0b4 (beta4)
 New Comment:

Php.ini issues aside, why would you want to add php folder to the path?
It should work without it, at least on newer windows versions. What
version of windows are you using?


Previous Comments:


[2004-02-18 17:26:30] php at koteroff dot ru

Description:

New PHP distribution directory structure is great. Now php.exe works
immediately after unpacking  modifying php.ini.



But with mod_php thinks are worse. To make him start I have to:

1. Set PHPRC environment variable equal to PHP5 directory path (to
search php.ini in this directory - for example, let it be
z:/usr/local/php5).

2. Manually add z:/usr/local/php5 to PATH to allow PHP search for
libmysql.dll, libeay32.dll etc. while loading extensions.



It is too importunate and makes mod_php usage greatly harder than CGI
version using. That's why I ask you to add the following features:



1. By default search php.ini not only in apache directory (it's silly)
and in windows directory (it's silly twice - nothing personal: nobody
wants to trash windows folder), but at php5apache.dll directory too.

2. Also add directory in which php5apache.dll resides to PATH (possibly
at php5apache startup code).



These changes will unversalize PHP and make mod_php installation not
harder than CGI installation. (I'd like to say thet a lot of people
uses Windows-PHP in debugging purposes. That's why they have 2 or 3
different version of PHP at the same server.)



To get current module name, we may use GetModuleFileName API call. To
set environment variable PATH GetEnvironmentVariable and
SetEnvironmentVariable may be used.



Please answer what do you thing about all of these?






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


#27227 [Csd-Opn]: Mixed case class names causes Fatal Error in Constructor call

2004-02-18 Thread waboring at 3gstech dot com
 ID:   27227
 User updated by:  waboring at 3gstech dot com
 Reported By:  waboring at 3gstech dot com
-Status:   Closed
+Status:   Open
 Bug Type: Zend Engine 2 problem
 Operating System: *
 PHP Version:  5CVS-2004-02-11
 Assigned To:  helly
 New Comment:

This isn't quite fixed yet.  Here is a sample that still breaks in
today's CVS.  This code works fine in php4



?php

class bTesting {



function blah() {

echo __CLASS__.::.__FUNCTION__.() calledbr\n;

}

}



class c extends bTesting {

function c() {

echo __CLASS__.::.__FUNCTION__.() called!!br\n;

$this-bTesting();

//FAILED ON LINE ABOVE

}

}



$obj = new c();

$obj-blah();

?





This outputs:

c::c() called!!



Fatal error: Call to undefined method c::bTesting() in
/home/waboring/devel/bug.php on line 12


Previous Comments:


[2004-02-15 19:28:42] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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.





[2004-02-11 20:33:03] [EMAIL PROTECTED]

Works fine with PHP 4 btw. :) (somehow I think this might be one for
Marcus to fix..?)







[2004-02-11 19:20:49] waboring at 3gstech dot com

Description:

I have 3 classes a, b extends a, c extends b.



b doesn't have constructor.



c class contructor calls b's constructor in an effort

to cascade constructor calls up the class heirarchy.



This works great until class 'a' is renamed to 'A'.



?php

/* This script works as one would expect.

  The foo class constructor gets called.

 */

class a {

function a() {

echo __CLASS__.::.__FUNCTION__. called!br\n;

}

}



class b extends a {



function blah() {

echo __CLASS__.::.__FUNCTION__.() calledbr\n;

}

}



class c extends b {

function c() {

echo __CLASS__.::.__FUNCTION__.() called!!br\n;

$this-b();

}

}



$obj = new c();

$obj-blah();



/* Output is

c::c() called!!

a::a called!

b::blah() called

*/

?





Reproduce code:
---
?php

/* 

  Notice that the only thing that is different here is the

  case of the 'a' class changed to 'A' in all the appropriate places. 
Now I get a Fatal error saying

c::b() doesn't exist?



*/



class A {

function A() {

echo __CLASS__.::.__FUNCTION__. called!br\n;

}

}



class b extends A {



function blah() {

echo __CLASS__.::.__FUNCTION__.() calledbr\n;

}

}



class c extends b {

function c() {

echo __CLASS__.::.__FUNCTION__.() called!!br\n;

$this-b();

//ERROR IN LINE ABOVE

}

}



$obj = new c();

$obj-blah();



/* Output is



c::c() called!!



Fatal error: Call to undefined method c::b() in
/home/waboring/devel/php/oop.php on line 18



*/

?

Expected result:

I expect that both of the scripts would work the same way.  I have many
classes that have Mixed case 

Actual result:
--
Fatal error: Call to undefined method c::b() in
/home/waboring/devel/php/oop.php on line 18









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


#27227 [Opn]: Mixed case class names causes Fatal Error in Constructor call

2004-02-18 Thread waboring at 3gstech dot com
 ID:   27227
 User updated by:  waboring at 3gstech dot com
 Reported By:  waboring at 3gstech dot com
 Status:   Open
 Bug Type: Zend Engine 2 problem
 Operating System: *
 PHP Version:  5CVS-2004-02-11
 Assigned To:  helly
 New Comment:

ERR 



Actually this is a more valid test.   sorry



?php

class A {

function A() {

echo __CLASS__.::.__FUNCTION__. called!br\n;

}

}



class bTesting extends A {



function blah() {

echo __CLASS__.::.__FUNCTION__.() calledbr\n;

}

}



class c extends bTesting {

function c() {

echo __CLASS__.::.__FUNCTION__.() called!!br\n;

$this-bTesting();

}

}



$obj = new c();

$obj-blah();

?



results in: 

c::c() called!!



Fatal error: Call to undefined method c::bTesting() in
/home/waboring/devel/bug.php on line 18


Previous Comments:


[2004-02-18 20:26:52] waboring at 3gstech dot com

This isn't quite fixed yet.  Here is a sample that still breaks in
today's CVS.  This code works fine in php4



?php

class bTesting {



function blah() {

echo __CLASS__.::.__FUNCTION__.() calledbr\n;

}

}



class c extends bTesting {

function c() {

echo __CLASS__.::.__FUNCTION__.() called!!br\n;

$this-bTesting();

//FAILED ON LINE ABOVE

}

}



$obj = new c();

$obj-blah();

?





This outputs:

c::c() called!!



Fatal error: Call to undefined method c::bTesting() in
/home/waboring/devel/bug.php on line 12



[2004-02-15 19:28:42] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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.





[2004-02-11 20:33:03] [EMAIL PROTECTED]

Works fine with PHP 4 btw. :) (somehow I think this might be one for
Marcus to fix..?)







[2004-02-11 19:20:49] waboring at 3gstech dot com

Description:

I have 3 classes a, b extends a, c extends b.



b doesn't have constructor.



c class contructor calls b's constructor in an effort

to cascade constructor calls up the class heirarchy.



This works great until class 'a' is renamed to 'A'.



?php

/* This script works as one would expect.

  The foo class constructor gets called.

 */

class a {

function a() {

echo __CLASS__.::.__FUNCTION__. called!br\n;

}

}



class b extends a {



function blah() {

echo __CLASS__.::.__FUNCTION__.() calledbr\n;

}

}



class c extends b {

function c() {

echo __CLASS__.::.__FUNCTION__.() called!!br\n;

$this-b();

}

}



$obj = new c();

$obj-blah();



/* Output is

c::c() called!!

a::a called!

b::blah() called

*/

?





Reproduce code:
---
?php

/* 

  Notice that the only thing that is different here is the

  case of the 'a' class changed to 'A' in all the appropriate places. 
Now I get a Fatal error saying

c::b() doesn't exist?



*/



class A {

function A() {

echo __CLASS__.::.__FUNCTION__. called!br\n;

}

}



class b extends A {



function blah() {

echo __CLASS__.::.__FUNCTION__.() calledbr\n;

}

}



class c extends b {

function c() {

echo __CLASS__.::.__FUNCTION__.() called!!br\n;

$this-b();

//ERROR IN LINE ABOVE

}

}



$obj = new c();

$obj-blah();



/* Output is



c::c() called!!



Fatal error: Call to undefined method c::b() in
/home/waboring/devel/php/oop.php on line 18



*/

?

Expected result:

I expect that both of the scripts would work the same way.  I have many
classes that have Mixed case 

Actual result:
--
Fatal error: Call to undefined method c::b() in
/home/waboring/devel/php/oop.php on line 18









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


#27227 [Opn-Bgs]: Mixed case class names causes Fatal Error in Constructor call

2004-02-18 Thread sniper
 ID:   27227
 Updated by:   [EMAIL PROTECTED]
 Reported By:  waboring at 3gstech dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Zend Engine 2 problem
 Operating System: *
 PHP Version:  5CVS-2004-02-11
 Assigned To:  helly
 New Comment:

There is no function called bTesting(), so why shouldn't it output an
error?? (I'd say it's bug in PHP4 where it magically works..)


Previous Comments:


[2004-02-18 20:32:14] waboring at 3gstech dot com

ERR 



Actually this is a more valid test.   sorry



?php

class A {

function A() {

echo __CLASS__.::.__FUNCTION__. called!br\n;

}

}



class bTesting extends A {



function blah() {

echo __CLASS__.::.__FUNCTION__.() calledbr\n;

}

}



class c extends bTesting {

function c() {

echo __CLASS__.::.__FUNCTION__.() called!!br\n;

$this-bTesting();

}

}



$obj = new c();

$obj-blah();

?



results in: 

c::c() called!!



Fatal error: Call to undefined method c::bTesting() in
/home/waboring/devel/bug.php on line 18



[2004-02-15 19:28:42] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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.





[2004-02-11 20:33:03] [EMAIL PROTECTED]

Works fine with PHP 4 btw. :) (somehow I think this might be one for
Marcus to fix..?)







[2004-02-11 19:20:49] waboring at 3gstech dot com

Description:

I have 3 classes a, b extends a, c extends b.



b doesn't have constructor.



c class contructor calls b's constructor in an effort

to cascade constructor calls up the class heirarchy.



This works great until class 'a' is renamed to 'A'.



?php

/* This script works as one would expect.

  The foo class constructor gets called.

 */

class a {

function a() {

echo __CLASS__.::.__FUNCTION__. called!br\n;

}

}



class b extends a {



function blah() {

echo __CLASS__.::.__FUNCTION__.() calledbr\n;

}

}



class c extends b {

function c() {

echo __CLASS__.::.__FUNCTION__.() called!!br\n;

$this-b();

}

}



$obj = new c();

$obj-blah();



/* Output is

c::c() called!!

a::a called!

b::blah() called

*/

?





Reproduce code:
---
?php

/* 

  Notice that the only thing that is different here is the

  case of the 'a' class changed to 'A' in all the appropriate places. 
Now I get a Fatal error saying

c::b() doesn't exist?



*/



class A {

function A() {

echo __CLASS__.::.__FUNCTION__. called!br\n;

}

}



class b extends A {



function blah() {

echo __CLASS__.::.__FUNCTION__.() calledbr\n;

}

}



class c extends b {

function c() {

echo __CLASS__.::.__FUNCTION__.() called!!br\n;

$this-b();

//ERROR IN LINE ABOVE

}

}



$obj = new c();

$obj-blah();



/* Output is



c::c() called!!



Fatal error: Call to undefined method c::b() in
/home/waboring/devel/php/oop.php on line 18



*/

?

Expected result:

I expect that both of the scripts would work the same way.  I have many
classes that have Mixed case 

Actual result:
--
Fatal error: Call to undefined method c::b() in
/home/waboring/devel/php/oop.php on line 18









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


#27221 [Com]: $_POST superglobal variable not populated after posting a form

2004-02-18 Thread aintlikenospam at www dot ravis dot org/contact/
 ID:   27221
 Comment by:   aintlikenospam at www dot ravis dot org/contact/
 Reported By:  patrick at studioemma dot be
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: Redhat 7.3
 PHP Version:  4.3.4
 New Comment:

I wasted 2 full days tracking down something that looks very similar to
this. In my case it's limited to IE and SSL only. Very intermitant.
What solved it for us was this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;831167



and adding 

SetEnvIf User-Agent .*MSIE.* nokeepalive ssl-unclean-shutdown

to our apache config in the ssl enabled virtualhost section. Give it a
shot and see if it works for you too.


Previous Comments:


[2004-02-18 18:21:48] steve dot carrico at louisville dot edu

I don't beleive this is a PHP bug.  We started receiving similar
problem reports at the university I work for after the latest Internet
Explorer security update was released.  I came across the following
Microsoft Knowledge Base article yesterday and the software update
linked under the Resolution section appears to fix the problem:



http://support.microsoft.com/default.aspx?scid=kb;en-us;831167



[2004-02-12 10:02:39] [EMAIL PROTECTED]

Can not reproduce using latest CVS (or even with 4.3.4)





[2004-02-12 05:10:24] patrick at studioemma dot be

I will wait for the definite release. I can however allready add these
comments:



- only occurs on SSL

- occurs when some fields (no reserved words as names) have spaces,
numeric values, and perhaps others.



In the meantime I moved to just HTTP instead of HTTPS



[2004-02-11 15:02:01] [EMAIL PROTECTED]

Just try the snapshot first.





[2004-02-11 14:51:49] patrick at studioemma dot be

my httpd.conf only mentions:



AddType application/x-httpd-php .php4 .php3 .phtml .php

AddType application/x-httpd-php-source .phps



However I have found a key to the origin: apparently the values I enter
in the form influence the problem. I have been able to reproduce but
cannot figure out any logic. I have to mention I'm only using a-zA-Z
and - signs..

it's like black magic...



I have not yet installed the snapshot, will definitely await final
release. I have to mention as well that I just upgraded to 4.3.4 from
4.3.2 where the problem occured as well.



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/27221

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


#27227 [Bgs-Opn]: Mixed case class names causes Fatal Error in Constructor call

2004-02-18 Thread waboring at 3gstech dot com
 ID:   27227
 User updated by:  waboring at 3gstech dot com
 Reported By:  waboring at 3gstech dot com
-Status:   Bogus
+Status:   Open
 Bug Type: Zend Engine 2 problem
 Operating System: *
 PHP Version:  5CVS-2004-02-11
 Assigned To:  helly
 New Comment:

because $c-bTesting() is calling the constructor of the bTesting
object. in php4, that cascades to the A class, as it should since the A
constructor exists, but the bTesting constructor doesn't.


Previous Comments:


[2004-02-18 21:32:58] [EMAIL PROTECTED]

There is no function called bTesting(), so why shouldn't it output an
error?? (I'd say it's bug in PHP4 where it magically works..)



[2004-02-18 20:32:14] waboring at 3gstech dot com

ERR 



Actually this is a more valid test.   sorry



?php

class A {

function A() {

echo __CLASS__.::.__FUNCTION__. called!br\n;

}

}



class bTesting extends A {



function blah() {

echo __CLASS__.::.__FUNCTION__.() calledbr\n;

}

}



class c extends bTesting {

function c() {

echo __CLASS__.::.__FUNCTION__.() called!!br\n;

$this-bTesting();

}

}



$obj = new c();

$obj-blah();

?



results in: 

c::c() called!!



Fatal error: Call to undefined method c::bTesting() in
/home/waboring/devel/bug.php on line 18



[2004-02-15 19:28:42] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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.





[2004-02-11 20:33:03] [EMAIL PROTECTED]

Works fine with PHP 4 btw. :) (somehow I think this might be one for
Marcus to fix..?)







[2004-02-11 19:20:49] waboring at 3gstech dot com

Description:

I have 3 classes a, b extends a, c extends b.



b doesn't have constructor.



c class contructor calls b's constructor in an effort

to cascade constructor calls up the class heirarchy.



This works great until class 'a' is renamed to 'A'.



?php

/* This script works as one would expect.

  The foo class constructor gets called.

 */

class a {

function a() {

echo __CLASS__.::.__FUNCTION__. called!br\n;

}

}



class b extends a {



function blah() {

echo __CLASS__.::.__FUNCTION__.() calledbr\n;

}

}



class c extends b {

function c() {

echo __CLASS__.::.__FUNCTION__.() called!!br\n;

$this-b();

}

}



$obj = new c();

$obj-blah();



/* Output is

c::c() called!!

a::a called!

b::blah() called

*/

?





Reproduce code:
---
?php

/* 

  Notice that the only thing that is different here is the

  case of the 'a' class changed to 'A' in all the appropriate places. 
Now I get a Fatal error saying

c::b() doesn't exist?



*/



class A {

function A() {

echo __CLASS__.::.__FUNCTION__. called!br\n;

}

}



class b extends A {



function blah() {

echo __CLASS__.::.__FUNCTION__.() calledbr\n;

}

}



class c extends b {

function c() {

echo __CLASS__.::.__FUNCTION__.() called!!br\n;

$this-b();

//ERROR IN LINE ABOVE

}

}



$obj = new c();

$obj-blah();



/* Output is



c::c() called!!



Fatal error: Call to undefined method c::b() in
/home/waboring/devel/php/oop.php on line 18



*/

?

Expected result:

I expect that both of the scripts would work the same way.  I have many
classes that have Mixed case 

Actual result:
--
Fatal error: Call to undefined method c::b() in
/home/waboring/devel/php/oop.php on line 18









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