#21036 [Opn]: messages doubled with Bcc: header
ID: 21036 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Mail Related Operating System: Win2000 Server PHP Version: 4.3.0RC3 New Comment: I think I may have found the possible cause of the problem. I'm new to programming, so please bear with me if I'm completely wrong. I was looking through the code for sendmail.c and in the section for SendText, somewhere around line 521, you strip the Bcc from the headers. This should work in theory, but shouldn't this be done *before* the Cc headers are done. If the code is executed in sequence, the 'cc' part of the Bcc: headers are being picked up as Cc: headers and the addresses are sent a message, then the full Bcc: header is picked up and the recipients are sent a second message. If this theory is correct, then wouldn't the problem be solved by moving the entire Bcc: header section, including the stripping function, to be run before the Cc: header section. That way the Bcc headers are found and the messages are sent, the header is then stripped out, and if there are no real Cc: headers, then nothing happens, but if there are Cc: headers, then they have not been stripped and the message will be sent as needed. I seem to be having trouble building PHP on my system, so I haven't been able to test this theory. Please tell me what you think of my hypothesis. Thanks again. Previous Comments: [2002-12-16 11:46:48] [EMAIL PROTECTED] Yes. I deleted the entire directory as well as the php4apache.dll and php4ts.dll files from the /WINNT/system32 directory and installed the fresh copy from the zip file. I tried it again just now to make sure that I wasn't missing something, but I still have this problem. Thanks for the quick reply. [2002-12-16 05:11:07] [EMAIL PROTECTED] Are you 100% sure you updated EVERY file in your system from the RC3 / snapshot package? [2002-12-15 21:37:24] [EMAIL PROTECTED] I found a similar bug report (ID#20707) for PHP4.3RC2. I tried the latest code linked to from there, as well as the Windows binary of RC3 offered on the main site page, but I still get the same result: Each To: recipient receives the message once, but all addresses listed in the Bcc: header recieves the message twice. I checked my mail server logs to insure it was not a server problem and confirmed that PHP was giving each address twice. Thank you for your help. -- Edit this bug report at http://bugs.php.net/?id=21036&edit=1
#21150 [Opn->Fbk]: Sapi module error
ID: 21150 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Redhat 8 PHP Version: 4.3.0RC4 New Comment: What are the contents of the libs/ directory? Previous Comments: [2002-12-22 19:05:13] [EMAIL PROTECTED] Sorry for my terrible english... I try to configure with the command sh configure --disable-debug --with-bz2=/usr/local --with-curl=/usr/local --with-dom=/usr/local --with-png-dir=/usr/local --with-gd=/usr/local --enable-gd-native-ttf --with-gdbm=/usr/local --with-gmp=/usr/local --with-jpeg-dir=/usr/local --with-xml --with-zlib=/usr/local --enable-exif --enable-ftp --enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm --enable-discard-path --enable-trans-sid --enable-wddx --with-kerberos --with-mysql=/usr/local/mysql --enable-bcmath --enable-shmop --enable-versioning --enable-calendar --enable-dbx --enable-dio --enable-mbstring --enable-mbstr-enc-trans --with-freetype-dir=/usr/local --with-mhash=/usr/local --with-mcal=/usr/local/mcal --with-pgsql=/usr/local/pgsql --with-openssl=shared,/usr/local/ssl --with-apxs=/usr/local/apache/bin/apxs Then I compile with 'make', and all goes ok But when I try to install php, with 'make install', I get the following error: [root@idave php-4.3.0RC4]# make install Installing PHP CLI binary:/usr/local/bin/ Installing PHP SAPI module [activating module `php4' in /usr/local/apache/conf/httpd.conf] cp libs/libphp4.so /usr/local/apache/libexec/libphp4.so cp: impossibile fare stat di `libs/libphp4.so': No such file or directory apxs:Break: Command failed with rc=1 make: *** [install-sapi] Error 1 [root@idave php-4.3.0RC4]# Note that I've previously installed PHP4.3.0RC2 and all went ok, with the same configure line! What's wrong? -- Edit this bug report at http://bugs.php.net/?id=21150&edit=1
#21195 [Opn->Ver]: Configure warnings/errors
ID: 21195 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified Bug Type: *Configuration Issues Operating System: Gentoo/Linux -PHP Version: 4.3.0RC4 +PHP Version: 4.3.0/4.4.0-dev Previous Comments: [2002-12-26 07:53:21] [EMAIL PROTECTED] ./configure --with-openssl --with-zlib --enable-bcmath --with-bz2 --enable-calendar --with-jpeg-dir --with-tiff-dir --with-db --enable-dba --with-flatfile --enable-dbase --enable-dio --with-dom --with-zlib-dir --with-dom-xslt --with-dom-exslt --enable-filepro --with-gd --enable-ftp --with-jpeg-dir --with-png-dir --with-xpm-dir --with-zlib-dir --with-ttf --with-freetype-dir --with-t1lib --enable-gd-native-ttf --with-gettext --with-hyperwave --with-iconv --with-imap --with-imap-ssl --with-java --enable-mbstring --enable-mbregex --with-mcrypt --with-mhash --with-mysql --with-mysql-sock --with-zlib-dir --with-ncurses --with-pdflib --with-jpeg-dir --with-png-dir --with-zlib-dir --with-tiff-dir --with-libedit --with-qtdom --with-mm --enable-shmop --with-snmp --enable-sockets --with-swf --enable-sysvmsg --enable-sysvsem --enable-sysvshm [2002-12-26 07:49:20] [EMAIL PROTECTED] during ./configure i saw following messages: checking for jpeg_read_header in -ljpeg... (cached) yes ./configure: line 1: cd: yes: No such file or directory checking for png_create_info_struct in -lpng... yes ./configure: line 1: cd: yes: No such file or directory checking for TIFFOpen in -ltiff... yes ./configure: line 1: cd: yes: No such file or directory checking for the location of zlib... /usr -- Edit this bug report at http://bugs.php.net/?id=21195&edit=1
#21206 [Opn->Fbk]: nesting level and recursive errors on make test... php fails
ID: 21206 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: RH Linux 7.2 PHP Version: 4.3.0RC4 New Comment: The failed test was incorrect and is no longer present in 4.3.0. The other problem maybe due to the fact that your php.ini directives tell php to load shared extensions that are now either compiled into PHP core or were compiled for previous versions. This could resolve in all kinds of erroneous behaviour. Check your php.ini for the extensions you load dynamically and try to determine which one (or more) is reponsible. Previous Comments: [2002-12-28 01:21:40] [EMAIL PROTECTED] I've also experienced this problem with the release version of PHP 4.3.0 on Redhat 7.2 My configure string is as follows './configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext=shared' '--with-ncurses' '--with-gmp' '--with-iconv-dir=/usr' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pear' '--with-png' '--with-pspell-dir=/usr' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-debugger' '--enable-exif' '--enable-ftp=shared' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql=/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans' '--disable-experimental-zts' '--with-apxs=/usr/sbin/apxs' [2002-12-26 19:54:03] [EMAIL PROTECTED] Well I have also tried using 4.4.0-dev and same issue. Now if I delete or move my original php.ini file and run I get one error still and it causes the same problem. If I install it any site using php fails. The error i get using make test if I delete the php.ini file is = FAILED TEST SUMMARY - Bug #20993 (referenced array key, makes array global) [tests/lang/bug20993.phpt] = [2002-12-26 17:31:57] [EMAIL PROTECTED] Warning: Nesting level too deep - recursive dependency? in Unknown on line 0 That error shows several times during the make test part of the install. During the install the ./configure... and make does ok with no errors. Then doing a make test fails on almost every test it performs. If I continue to do a make install afterwards it breaks the server down so that most to all sites using php do not work. I have verified this with the latest stable release, 4.3.0-dev, 4.3.0RC2, 4.3.0RC3, and now 4.3.0RC4. Right now I am running 4.2.4-dev and is working fine. I have also tried a few different configure commands to hopefully resolve this issue but with no luck. Current configure... './configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd-dir=/home/instkit/gd-2.0.4' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext=shared' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/u
#21206 [Com]: nesting level and recursive errors on make test... php fails
ID: 21206 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: RH Linux 7.2 PHP Version: 4.3.0RC4 New Comment: I've also experienced this problem with the release version of PHP 4.3.0 on Redhat 7.2 My configure string is as follows './configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext=shared' '--with-ncurses' '--with-gmp' '--with-iconv-dir=/usr' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pear' '--with-png' '--with-pspell-dir=/usr' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-debugger' '--enable-exif' '--enable-ftp=shared' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql=/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans' '--disable-experimental-zts' '--with-apxs=/usr/sbin/apxs' Previous Comments: [2002-12-26 19:54:03] [EMAIL PROTECTED] Well I have also tried using 4.4.0-dev and same issue. Now if I delete or move my original php.ini file and run I get one error still and it causes the same problem. If I install it any site using php fails. The error i get using make test if I delete the php.ini file is = FAILED TEST SUMMARY - Bug #20993 (referenced array key, makes array global) [tests/lang/bug20993.phpt] = [2002-12-26 17:31:57] [EMAIL PROTECTED] Warning: Nesting level too deep - recursive dependency? in Unknown on line 0 That error shows several times during the make test part of the install. During the install the ./configure... and make does ok with no errors. Then doing a make test fails on almost every test it performs. If I continue to do a make install afterwards it breaks the server down so that most to all sites using php do not work. I have verified this with the latest stable release, 4.3.0-dev, 4.3.0RC2, 4.3.0RC3, and now 4.3.0RC4. Right now I am running 4.2.4-dev and is working fine. I have also tried a few different configure commands to hopefully resolve this issue but with no luck. Current configure... './configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd-dir=/home/instkit/gd-2.0.4' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext=shared' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pear' '--with-png' '--with-pspell-dir=/usr' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-debugger' '--enable-exif' '--enable-ftp=shared' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--
#21233 [Opn->Bgs]: cgi/cli binary compile failure
ID: 21233 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: linux debian testing/unstable PHP Version: 4.3.0 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. It appears that on your system, the LIBC's fnmatch.h got over written by Apache 1x's fnmatch.h, which requires ap_config.h header. This is NOT a PHP bug. Previous Comments: [2002-12-27 22:48:02] [EMAIL PROTECTED] I'm trying to compile php 4.3.0 as a cgi binary for use as a cli on x86 with Debian testing/unstable kernel 2.4.18 vanilla(I compiled it myself). it configures just fine, but fails on compile with the following error: In file included from /mnt/storage/php-4.3.0/ext/standard/file.c:115: /usr/local/include/fnmatch.h:38: ap_config.h: No such file or directory make: *** [ext/standard/file.lo] Error 1 I find this same problem with 4.3.0RC3 and RC4, but with 4.2.3 it compiles just fine. here is my ./configure line: ./configure --with-config-file-path=/etc/php --without-pear --with-openssl --with-zlib --enable-bc --enable-calender --with-jpeg-dir --with-tiff-dir --enable-ftp --with-mysql --with-ncurses --with-regex=system --enable-tokenizer --prefix=/usr/local/php-cli -- Edit this bug report at http://bugs.php.net/?id=21233&edit=1
#21231 [Opn->Fbk]: ./configure fails on cURL check
ID: 21231 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Linux - Red Hat 7.3 PHP Version: 4.3.0 New Comment: I have no trouble compiling PHP 4.3 against curl 7.10.2, it is possible that curl library is not in the path or the path you've specified is incorrect. Try putting the output of 'curl-config --prefix' as the value for --with-curl. Ex: --with-curl=`curl-config --prefix Previous Comments: [2002-12-27 22:17:57] [EMAIL PROTECTED] Successfully obtained the PHP 4.3.0 release from anonymous CVS. ./buildconf ran successfully, however, ./configure fails with the following error: "checking for cURL 7.9.8 or greater... configure: error: cURL version 7.9.8 or later is required to compile php with cURL support" I updated cURL with the latest version (7.10.2) as evidenced by: "[root@server php4]# curl -V curl 7.10.2 (i686-pc-linux-gnu) libcurl/7.10.2 OpenSSL/0.9.6b zlib/1.1.3" however, I still get the error when attempting to run ./configure. -- Edit this bug report at http://bugs.php.net/?id=21231&edit=1
#21224 [Opn->Fbk]: apache configure fails at php module
ID: 21224 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: What version of libtool are you using? Previous Comments: [2002-12-27 16:58:54] [EMAIL PROTECTED] apache 1.3.27 configure script fails at this point: with gcc version 2.95.2 and GNU ld version 2.13 + doing sanity check on compiler and options ** A test compilation with your Makefile configuration ** failed. The below error output from the compilation ** test will give you an idea what is failing. Note that ** Apache requires an ANSI C Compiler, such as gcc. Error Output for sanity check make[1]: Entering directory `/usr/local/src/apache/apache_1.3.27/src/helpers' cd ..; gcc -O3 -DDYNAMIC_MODULE_LIMIT=0 -I/usr/local/include/mysql -DSOLARIS2=280 -DMOD_SSL=208111 -DEAPI -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` -L/usr/local/ssl/lib -o helpers/dummy helpers/dummy.c -L/usr/local/lib/mysql -lmysqlclient -R/usr/ucblib -R/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -R/usr/local/ssl/lib -R/usr/local/lib -R/opt/sfw/lib -R/usr/local/src/apache/imap-2002.RC5/c-client -R/usr/local/lib/mysql -L/usr/ucblib -L/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -L/usr/local/ssl/lib -L/usr/local/lib -L/opt/sfw/lib -L/usr/local/src/apache/imap-2002.RC5/c-client -L/usr/local/lib/mysql -Lmodules/php4 -L../modules/php4 -L../../modules/php4 -lmodphp4 -export-symbols /usr/local/src/apache/php-4.3.0/sapi/apache/php.sym -L/usr/ucblib -L/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -L/usr/local/ssl/lib -L/usr/local/lib -L/opt/sfw/lib -L/usr/local/src/apache/imap-2002.RC5/c-client -L/usr/local/lib/mysql -lc-client -lmm -lmysqlclient -lmcrypt -lltdl -lcrypt -lpam -lgd -lpng -lz -ljpeg -lgdbm -lcurl -lz -lcrypt -lssl -lcrypto -lresolv -lm -ldl -lnsl -lsocket -lgcc -lcrypt -lcurl -ldl -lsocket -lnsl -lsocket -lnsl -lpthread -lssl -lcrypto ld: fatal: file /usr/local/src/apache/php-4.3.0/sapi/apache/php.sym: unknown file type ld: fatal: File processing errors. No output written to helpers/dummy collect2: ld returned 1 exit status make[1]: *** [dummy] Error 1 make[1]: Leaving directory `/usr/local/src/apache/apache_1.3.27/src/helpers' = End of Error Report = -- Edit this bug report at http://bugs.php.net/?id=21224&edit=1
#20965 [Fbk->NoF]: Urgent - Users getting same session id?
ID: 20965 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Session related Operating System: Linux PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-12 15:31:18] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-12 13:16:09] [EMAIL PROTECTED] I am running PHP version 4.2.3. [2002-12-12 11:15:06] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2002-12-12 10:38:30] [EMAIL PROTECTED] php session some times share the same session id with different users and this allows users to access another user's login and account info.. This is a serious security threat! Pls help. -- Edit this bug report at http://bugs.php.net/?id=20965&edit=1
#20954 [Fbk->NoF]: Serious problem , unknown reason
ID: 20954 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.3.0RC3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-12 11:16:32] [EMAIL PROTECTED] Try Apache 1.3.27..apache 2 is not ready for production.. [2002-12-12 11:00:49] [EMAIL PROTECTED] More...If I access the page at the server, everything are fine, however, those alien words will only appears when I use other computers or through proxy to access it. [2002-12-12 10:36:19] [EMAIL PROTECTED] I try not to use sapi with php4apache2.dll if I use php.exe ---> same Error very interesting that if I use php-cgi.exe All are fine. [2002-12-12 07:37:28] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. It's segfaulting, better get that off, or Windows XP will be Windows ExPired pretty soon. [2002-12-12 05:45:52] [EMAIL PROTECTED] te apache version should 2.0.43 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/20954 -- Edit this bug report at http://bugs.php.net/?id=20954&edit=1
#19113 [Fbk->NoF]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
ID: 19113 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache related Operating System: FreeBSD 4.6.2 PHP Version: 4.2.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-18 07:09:42] [EMAIL PROTECTED] Sorry, you don't understand the problem. The problem is that apache returns "HTTP 200 OK" on CONNECT request, but does NOT really connect to specified addrress. If it is possible to connect through your server to outside, then it's problem of your misconfigured proxy. [2002-12-16 13:54:03] [EMAIL PROTECTED] This bug is VERY serious. Our web servers have be attacked and used for relaying SPAM. Spammers are using the CONNECT command to proxy to open relay servers masking their IP addresses with ours. [2002-12-12 05:52:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-12 05:19:30] [EMAIL PROTECTED] I was now able reproduce this problem, but only in case when index.php was in DocumentRoot of first defined name-based virtual server (which is accepted as the default on that IP/port in such case), and index.php was the default script to execute (if there was something before index.php in DirectoryIndex and if it also existed in DocumentRoot of the default vhost, the bug did not apply). Therefore, i think it is really a php bug I reproduced this with Apache-1.3.26+php-4.1.2 on debian GNU/linux 3.0-woody and also Apache-1.3.27+php-4.2.3 on FreeBSD-4.6.2 [2002-12-03 10:01:43] [EMAIL PROTECTED] Hello, I also have problems with this. However, using apache-1.2.27+mod_ssl2.8.11 and php-4.2.3 i was not able to reproduce this problem with defined way. I think that is not php-related. 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/19113 -- Edit this bug report at http://bugs.php.net/?id=19113&edit=1
#18271 [Fbk->NoF]: Page load hangs accessing certain MSSQL data
ID: 18271 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: MSSQL related Operating System: Win2000 Server PHP Version: 4.2.1 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-07 01:42:06] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-07-12 23:55:04] [EMAIL PROTECTED] I eventually figured out that the problem was related directly to the "kilometres" column of the table, which was of type real. I changed the data type of the column to "decimal" - this was more appropriate for the data anyway. The column contains odometer readings, numbers in the range 0 - 40 which either had one decimal place or no fractional part at all. The problems instantly disappeared. It seems that something in the php_mssql extension has trouble with the real data type, in certain circumstances. Because I'm happy to use the decimal data type on this ocassion, my problem is solved, but I would still regard this as an open bug report. I'm happy to do more testing on demand, if it would help the cause. [2002-07-12 04:20:59] [EMAIL PROTECTED] Using a process of elimination (commenting out blocks of code), I tracked down what was causing the hang. As it happens, it is all because of a certain query on the page. If PHP tries to run this query, it hangs, and the page doesn't return anything at all. A bit of experimentation with the query revealed that the issue is directly related to one particular table in my database, odometer_log. Some attempts to query this table cause the hang, do not pass GO do not collect 200 dollars. No error is reported or logged by either PHP or SQL Server. There's nothing very interesting about the table that should cause PHP to drop the bundle. Here's the table definition: CREATE TABLE odometer_log ( id int not null identity(1,1) primary key, car int not null references motor_vehicle(id), kilometres real not null, date datetime not null, type int not null references odometer_log_type(id) ) As you can see, it's all pretty standard. No exotic binary data types or the like. I am able to open (and query) the table in SQL Server Enterprise Manager without any hassles, and likewise using Linked Tables in MS Access. So the problem seems not to be within the data table itself, or ODBC, and rather something to do with how the php_mssql extension accesses it. Results of various query tests on the table (through PHP)are as follows: SELECT * FROM odometer_log: Hangs SELECT COUNT(*) FROM odometer_log: Succeeds SELECT * FROM odometer_log WHERE car=63: Succeeds SELECT * FROM odometer_log WHERE car=88: Hangs So you might think that the error was being caused by certain car IDs, right? Well, not quite, since there's no significant difference between the data for car 63 and car 88. But to prove the point, see this next series of results: SELECT * FROM odometer_log WHERE car < 10: Succeeds SELECT * FROM odometer_log WHERE car < 10 ORDER BY car: Hangs SELECT * FROM odometer_log WHERE car = 3: Succeeds SELECT * FROM odometer_log WHERE car > 2 and car < 4: Hangs SELECT * FROM odometer_log WHERE car = 9: Hangs SELECT * FROM odometer_log WHERE car > 8 and car < 10: Hangs SELECT * FROM odometer_log WHERE car > 2 and car < 10: Hangs Try as I might, I can't think of a single rational explanation for this behaviour, nor can I think of a distinguishing factor between the queries which work and those which fail. Please help before I have an aneurism! [2002-07-12 01:39:30] [EMAIL PROTECTED] Have confirmed that the error occurs using Mozilla 0.9.4 and Netscape Communicator 4.78 under Mandrake Linux. These are older browsers, but it is clear that the error isn't IE6 specific. [2002-07-11 05:06:45] [EMAIL PROTECTED] Upgraded to 4.2.1, no change. Did some more searching of the bugs database, found 15324 and 14937 seemed to be similar problems to mine, but didn't find any solutions. It's becoming evident that the request is being passed to php.exe, but that PHP immediately fails to process the script, and instead of responding with an error, it just hangs. IIS reacts to this non-response by dropping out a 502 error co
#21229 [Opn->Csd]: Won't compile with roxen options
ID: 21229 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Debian 2.2 PHP Version: 4.3.0 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-12-27 19:40:41] [EMAIL PROTECTED] ./configure --with-roxen=/usr/local/roxen/server compiled 4.2.3 yesterday, install worked great. Had to upgrade to 4.3.0 because of the setcookie() bug. configure runs perfectly, in the end of the make-procedure, it quits. Wont make install either. roxen.c -o sapi/roxen/roxen.lo /php-4.3.0/sapi/roxen/roxen.c: In function `php_roxen_startup': /php-4.3.0/sapi/roxen/roxen.c:476: too few arguments to function `php_module_startup' make: *** [sapi/roxen/roxen.lo] Error 1 mactorget:/php-4.3.0# cd /usr/local/roxen/server/ Me -> :( Solution? -- Edit this bug report at http://bugs.php.net/?id=21229&edit=1
#21234 [Opn->Fbk]: Cannot load "php4apache2.dll" into Apache 2.039
ID: 21234 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.3.0 New Comment: Are you sure that all the installed dlls (perhaps in the windows system directory) are updated by those bundled in 4.3.0? And did you try the latest version of Apache2 (2.0.43)? Previous Comments: [2002-12-28 00:38:58] [EMAIL PROTECTED] I tried to run a strace, but strace apparently doesn't work on Winxp (blank output). Also note the error is "specifed procedure" not found. If I take out php4ts.dll then it says "specified module". Is there an alternative to strace I can use on Winxp for tracing which file is missing? [2002-12-27 23:32:44] [EMAIL PROTECTED] Here's the error when I type: apache -k install Syntax error on line 173 of D:/FoxServ/Apache/conf/httpd.conf: Cannot load D:/FoxServ/php/sapi/php4apache2.dll into server: The specified procedure could not be found. I disabled loading any optional PHP modules. PHP 4.23 worked with the exact same setup. I tried using php4apache2.dll from PHP 4.23, Apache and PHP loaded successfully. But when I load a php script using fopen(), Apache crashes, along with the computer. I coppied php4ts.lib and php4ts.dll to the directory where php4apache2.dll is. Perhaps there are additional libraries PHP 4.3 need but 4.23 didn't. -- Edit this bug report at http://bugs.php.net/?id=21234&edit=1
#21235 [Opn->Bgs]: over load in mailbox for this virus mail want to help stop this.
ID: 21235 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type:Unknown/Other Function PHP Version: 4.3.0 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. Previous Comments: [2002-12-28 00:40:47] [EMAIL PROTECTED] Sorry it is addressed to my yahoo mail (confused since sbc merged w/ yahoo) [EMAIL PROTECTED] I will save this mail in case you want to see it. [2002-12-28 00:37:30] [EMAIL PROTECTED] My mailbox has been overflowing with tainted mail(have not opened the attachment ) scanned before hand. it reads after scan for virus:virus W32.Yaha.H@mm The person that sends this is using famous peoples names(actors) What else can I do for you to help? -- Edit this bug report at http://bugs.php.net/?id=21235&edit=1
#21235 [Com]: over load in mailbox for this virus mail want to help stop this.
ID: 21235 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type:Unknown/Other Function PHP Version: 4.3.0 New Comment: Sorry it is addressed to my yahoo mail (confused since sbc merged w/ yahoo) [EMAIL PROTECTED] I will save this mail in case you want to see it. Previous Comments: [2002-12-28 00:37:30] [EMAIL PROTECTED] My mailbox has been overflowing with tainted mail(have not opened the attachment ) scanned before hand. it reads after scan for virus:virus W32.Yaha.H@mm The person that sends this is using famous peoples names(actors) What else can I do for you to help? -- Edit this bug report at http://bugs.php.net/?id=21235&edit=1
#21226 [Ver->Bgs]: function parse_url() fails
ID: 21226 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Bogus Bug Type: *URL Functions Operating System: w2000 PHP Version: 4.3.0 Assigned To: iliaa 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 Port can only be a numeric number from 0-9, although in reality the port range is from 1-65535, clearly a non numeric port number is not valid, hence invalidating the passed URL. The 2nd example is also wrong, without the '/' between the port & the rest of the request the code MUST assume that the following data is part of the port, hence the URL is not valid once again. This is NOT a bug. Previous Comments: [2002-12-27 19:21:59] [EMAIL PROTECTED] Add / after end of port part is a good solution. Thanks. Do you consider that it's a bug or parse_url is url RFC compliant ? [2002-12-27 19:04:18] [EMAIL PROTECTED] Seems to come from 'port' part of url. If we consider this : user:password@host?foo works fine, user:password@host:port?foo fails but user:password@host?foo:port works and returns port number in $p_url[port] but it's not correct [2002-12-27 19:00:53] [EMAIL PROTECTED] Some more info: port has to be numeric and less than 5 digits long. The bug part seems to be that parse_url() doesn't recognize the end of port part if '/' is missing. So $url="http://user:[EMAIL PROTECTED]:80/?foo";; works as expected. [2002-12-27 18:49:37] [EMAIL PROTECTED] Verified on Windows and Linux ZTS builds. Assigning to Ilia. [2002-12-27 18:47:38] [EMAIL PROTECTED] Does not working on 4.3.0RC4 AND 4.3.0 final too 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/21226 -- Edit this bug report at http://bugs.php.net/?id=21226&edit=1
#21234 [Opn]: Cannot load "php4apache2.dll" into Apache 2.039
ID: 21234 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.3.0 New Comment: I tried to run a strace, but strace apparently doesn't work on Winxp (blank output). Also note the error is "specifed procedure" not found. If I take out php4ts.dll then it says "specified module". Is there an alternative to strace I can use on Winxp for tracing which file is missing? Previous Comments: [2002-12-27 23:32:44] [EMAIL PROTECTED] Here's the error when I type: apache -k install Syntax error on line 173 of D:/FoxServ/Apache/conf/httpd.conf: Cannot load D:/FoxServ/php/sapi/php4apache2.dll into server: The specified procedure could not be found. I disabled loading any optional PHP modules. PHP 4.23 worked with the exact same setup. I tried using php4apache2.dll from PHP 4.23, Apache and PHP loaded successfully. But when I load a php script using fopen(), Apache crashes, along with the computer. I coppied php4ts.lib and php4ts.dll to the directory where php4apache2.dll is. Perhaps there are additional libraries PHP 4.3 need but 4.23 didn't. -- Edit this bug report at http://bugs.php.net/?id=21234&edit=1
#21235 [NEW]: over load in mailbox for this virus mail want to help stop this.
From: [EMAIL PROTECTED] Operating system: PHP version: 4.3.0 PHP Bug Type: Unknown/Other Function Bug description: over load in mailbox for this virus mail want to help stop this. My mailbox has been overflowing with tainted mail(have not opened the attachment ) scanned before hand. it reads after scan for virus:virus W32.Yaha.H@mm The person that sends this is using famous peoples names(actors) What else can I do for you to help? -- Edit bug report at http://bugs.php.net/?id=21235&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21235&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21235&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21235&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21235&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21235&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21235&r=support Expected behavior: http://bugs.php.net/fix.php?id=21235&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21235&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21235&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21235&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21235&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21235&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21235&r=isapi
#21234 [NEW]: Cannot load "php4apache2.dll" into Apache 2.039
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.3.0 PHP Bug Type: Apache2 related Bug description: Cannot load "php4apache2.dll" into Apache 2.039 Here's the error when I type: apache -k install Syntax error on line 173 of D:/FoxServ/Apache/conf/httpd.conf: Cannot load D:/FoxServ/php/sapi/php4apache2.dll into server: The specified procedure could not be found. I disabled loading any optional PHP modules. PHP 4.23 worked with the exact same setup. I tried using php4apache2.dll from PHP 4.23, Apache and PHP loaded successfully. But when I load a php script using fopen(), Apache crashes, along with the computer. I coppied php4ts.lib and php4ts.dll to the directory where php4apache2.dll is. Perhaps there are additional libraries PHP 4.3 need but 4.23 didn't. -- Edit bug report at http://bugs.php.net/?id=21234&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21234&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21234&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21234&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21234&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21234&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21234&r=support Expected behavior: http://bugs.php.net/fix.php?id=21234&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21234&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21234&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21234&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21234&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21234&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21234&r=isapi
#21233 [NEW]: cgi/cli binary compile failure
From: [EMAIL PROTECTED] Operating system: linux debian testing/unstable PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: cgi/cli binary compile failure I'm trying to compile php 4.3.0 as a cgi binary for use as a cli on x86 with Debian testing/unstable kernel 2.4.18 vanilla(I compiled it myself). it configures just fine, but fails on compile with the following error: In file included from /mnt/storage/php-4.3.0/ext/standard/file.c:115: /usr/local/include/fnmatch.h:38: ap_config.h: No such file or directory make: *** [ext/standard/file.lo] Error 1 I find this same problem with 4.3.0RC3 and RC4, but with 4.2.3 it compiles just fine. here is my ./configure line: ./configure --with-config-file-path=/etc/php --without-pear --with-openssl --with-zlib --enable-bc --enable-calender --with-jpeg-dir --with-tiff-dir --enable-ftp --with-mysql --with-ncurses --with-regex=system --enable-tokenizer --prefix=/usr/local/php-cli -- Edit bug report at http://bugs.php.net/?id=21233&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21233&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21233&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21233&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21233&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21233&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21233&r=support Expected behavior: http://bugs.php.net/fix.php?id=21233&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21233&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21233&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21233&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21233&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21233&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21233&r=isapi
#21232 [NEW]: Unresolved references to PQsetnonblocking
From: [EMAIL PROTECTED] Operating system: RedHat Linux 6.2 PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: Unresolved references to PQsetnonblocking I have verson 6.5.2 of Postgresql installed and have --with-pgsql on my configure command line for PHP. Version 4.3.0 fails to compile complaining about unresolved references to the function, PQsetnonblocking. I should probably upgrade my postgres installation but I decided to try and resolve this problem with PHP. I discovered that in ext/pgsql/pgsql.c the PQsetnonblocking function is referred to using a macro, PQ_SETNONBLOCKING which is defined to be 0 if HAVE_PQSETNONBLOCKING is set. However, in the function php_pgsql_slush_query() in ext/pgsql/pgsql.c the function PQsetnonblocking() is referred to using its real name instead of the macro: on lines 2838 and 2846. I edited thos two lines to use the PQ_SETNONBLOCKING macro and now PHP compiles without error. -- Edit bug report at http://bugs.php.net/?id=21232&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21232&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21232&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21232&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21232&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21232&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21232&r=support Expected behavior: http://bugs.php.net/fix.php?id=21232&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21232&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21232&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21232&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21232&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21232&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21232&r=isapi
#21231 [NEW]: ./configure fails on cURL check
From: [EMAIL PROTECTED] Operating system: Linux - Red Hat 7.3 PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: ./configure fails on cURL check Successfully obtained the PHP 4.3.0 release from anonymous CVS. ./buildconf ran successfully, however, ./configure fails with the following error: "checking for cURL 7.9.8 or greater... configure: error: cURL version 7.9.8 or later is required to compile php with cURL support" I updated cURL with the latest version (7.10.2) as evidenced by: "[root@server php4]# curl -V curl 7.10.2 (i686-pc-linux-gnu) libcurl/7.10.2 OpenSSL/0.9.6b zlib/1.1.3" however, I still get the error when attempting to run ./configure. -- Edit bug report at http://bugs.php.net/?id=21231&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21231&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21231&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21231&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21231&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21231&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21231&r=support Expected behavior: http://bugs.php.net/fix.php?id=21231&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21231&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21231&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21231&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21231&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21231&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21231&r=isapi
#21230 [Opn->Bgs]: Refresh Problem
ID: 21230 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Windows 2000 Server PHP Version: 4.3.0 New Comment: This sounds like a question for the phpbb guys. And by the way, Apache2+PHP is still very much experimental. I would suggest going back to Apache 1.3. Previous Comments: [2002-12-27 21:40:32] [EMAIL PROTECTED] I have been using PHP for a phpbb forum. Until recently i have been using apache 1.3 with version 4.23 of PHP, which has been working fine, but today I upgraded to Apache 2 with version 4.30 of PHP, and have experienced some problems, although the forum actually works, it has trouble refreshing, for example when i post a message it accepts that i've posted the message, but however when i return to the forum, the message has not appeared. Even clicking refresh on my browser does not work, The only way to refresh the page is to delete my history and offline files, and then press refresh again. I do not think this is a problem with the forum itself as I have not touched any of the files since I have upgraded. -- Edit this bug report at http://bugs.php.net/?id=21230&edit=1
#20951 [WFx->Opn]: PHP shell functions always call cmd.exe - potential security issue
ID: 20951 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Won't fix +Status: Open Bug Type: IIS related Operating System: Windows .Net Server 2003 RC2 PHP Version: 4CVS-2002-12-11 (dev) New Comment: Bummer. You should at least consider making this optional in the future (via an INI setting). Do you remember what problems you ran into before that were fixed by calling CMD.EXE? I went over this several times and didn't find a good reason to ALWAYS call CMD.EXE. Any webserver would definately web more secure if PHP didn't require access to CMD.EXE to call external programs. The Deny ACL instituted by Windows.Net Server just hilights how much a security concern Microsoft thought it was Previous Comments: [2002-12-26 20:19:15] [EMAIL PROTECTED] There were many other probmlems with executing applications from within a web server environment that were solved by requiring the execution through cmd /c. I guess system administrators would have to configure there servers accordingly. [2002-12-11 23:16:20] [EMAIL PROTECTED] Windows.Net Server 2003 has instituted a new security measure that causes problems with any of the shell related functions in PHP. Windows.Net Server changes the ACL's on EXE's in the %windir%\system32 subdirectory. In particular CMD.EXE can no longer be executed by the "anonymous" user account (ie, IUSR_COMPUTERNAME)--there is a specific Deny ACL created by the Windows.Net Server installer. Since PHP calls CMD.EXE to execute any external shell program PHP requires that CMD.EXE be reconfigured for anonymous access anytime a PHP page needs to call an external program. This design is no longer a good idea because PHP forces the web administrator to open up a potential security hole in the system by re-enabling access to CMD.EXE. The shell functions in PHP should call the application directly instead of always calling CMD.EXE? If the PHP programmer wants to call a feature of the CMD intreperter then he should be forced to call the shell command like `CMD /C dir *.*`; Only then would the administrator be required to allow access to the command intreperter. Please consider this modification as it will make Windows.Net Server more secure when running PHP. Or at least add configuration option to PHP.INI that will modify the behavior of the shell functions to no longer directly call CMD.EXE Thank you! -- Edit this bug report at http://bugs.php.net/?id=20951&edit=1
#21230 [NEW]: Refresh Problem
From: [EMAIL PROTECTED] Operating system: Windows 2000 Server PHP version: 4.3.0 PHP Bug Type: Apache2 related Bug description: Refresh Problem I have been using PHP for a phpbb forum. Until recently i have been using apache 1.3 with version 4.23 of PHP, which has been working fine, but today I upgraded to Apache 2 with version 4.30 of PHP, and have experienced some problems, although the forum actually works, it has trouble refreshing, for example when i post a message it accepts that i've posted the message, but however when i return to the forum, the message has not appeared. Even clicking refresh on my browser does not work, The only way to refresh the page is to delete my history and offline files, and then press refresh again. I do not think this is a problem with the forum itself as I have not touched any of the files since I have upgraded. -- Edit bug report at http://bugs.php.net/?id=21230&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21230&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21230&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21230&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21230&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21230&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21230&r=support Expected behavior: http://bugs.php.net/fix.php?id=21230&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21230&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21230&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21230&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21230&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21230&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21230&r=isapi
#21229 [NEW]: Won't compile with roxen options
From: [EMAIL PROTECTED] Operating system: Debian 2.2 PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: Won't compile with roxen options ./configure --with-roxen=/usr/local/roxen/server compiled 4.2.3 yesterday, install worked great. Had to upgrade to 4.3.0 because of the setcookie() bug. configure runs perfectly, in the end of the make-procedure, it quits. Wont make install either. roxen.c -o sapi/roxen/roxen.lo /php-4.3.0/sapi/roxen/roxen.c: In function `php_roxen_startup': /php-4.3.0/sapi/roxen/roxen.c:476: too few arguments to function `php_module_startup' make: *** [sapi/roxen/roxen.lo] Error 1 mactorget:/php-4.3.0# cd /usr/local/roxen/server/ Me -> :( Solution? -- Edit bug report at http://bugs.php.net/?id=21229&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21229&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21229&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21229&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21229&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21229&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21229&r=support Expected behavior: http://bugs.php.net/fix.php?id=21229&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21229&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21229&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21229&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21229&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21229&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21229&r=isapi
#21228 [NEW]: output handler 'ob_gzhandler' cannot be used twice
From: [EMAIL PROTECTED]
Operating system: Windows 2000 Server
PHP version: 4.3.0
PHP Bug Type: *Compression related
Bug description: output handler 'ob_gzhandler' cannot be used twice
If I use ob_start("ob_gzhandler") function I get an error message: "PHP
Warning: ob_gzhandler() [ref.outcontrol]: output
handler 'ob_gzhandler' cannot be used twice in c:\web\test.php3 on line
11". The same script runs fine on 4.2.3. Interestingly, on version 4.3.0
ob_get_level() returns 2 and on 4.2.3 the return value is 1. I'm using
Windows 2000 Server/IIS5. PHP is configured in CGI mode.
Here's the script:
//---start---
<%
ob_start("ob_gzhandler");
%>
This is a test. ob_get_level: <% echo ob_get_level(); %>
<%
if(ob_get_level()){
ob_end_flush();
}
%>
//---end---
And here's the essential configurations from the 'php.ini' file:
output_buffering = 4096
output_handler =
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func=
allow_call_time_pass_reference = Off
If I set "output_handler = ob_gzhandler" and remove the
ob_start("ob_gzhandler") from the script it's working on 4.3.0 as well.
However, this way the compression is always on and I can't determine
myself when to use it.
--
Edit bug report at http://bugs.php.net/?id=21228&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21228&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21228&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21228&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21228&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21228&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21228&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21228&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21228&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21228&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21228&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21228&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21228&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21228&r=isapi
#21222 [Bgs]: problem with dirname
ID: 21222
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Directory function related
Operating System: Win2k
PHP Version: 4.3.0
New Comment:
See also:
http://bugs.php.net/bug.php?id=20895
Maybe someone with a clue (unlike me) can document this.
Previous Comments:
[2002-12-27 15:49:00] [EMAIL PROTECTED]
No, the trailing / the docs talk about are cases where you actually
have a trailing / in the source path. eg. /some/path/
It does not mean that the trailing path of the returned string will be
stripped.
[2002-12-27 15:46:26] [EMAIL PROTECTED]
That reasoning doesn't quite go along with what the documentation says,
IMHO:
(quoted from http://www.php.net/dirname)
"[...]Essentially, this means that if there are no slashes in path , a
dot ('.') is returned, indicating the current directory. Otherwise, the
returned string is path with any trailing /component removed.[...]"
So for the input '/test.php', the first case (no slashes in path)
obviously doesn't apply, since there is a slash contained in the path
in question.
Now, the second case states that the returned string is the path
('/test.php') with any trailing /component (in this case '/test.php')
removed, i.e. simply ''.
So there seems to be some kind of contradiction between the manual and
what you said, could your elaborate on that, please? Apologies if I'm
missing the point,
Michael
PS: Even if the behaviour was changed to return '/' instead of an empty
string, the transformation of '/' to the default directory separator
should still be officially documented (and not in the user comments).
[2002-12-27 15:27:42] [EMAIL PROTECTED]
Your expectation is simply wrong. dirname() is documented to return
the directory component of a pathname you feed it. You fed it
/test.php and it gave you back / (or the Windows equivalent thereof) as
expected.`
[2002-12-27 15:24:46] [EMAIL PROTECTED]
Hi there,
';
echo '"' . dirname($_SERVER['REQUEST_URI']) . '"';
?>
produces following output...
/test.php
"\"
Instead of the output above, i expected
/test.php
""
Can someone confirm this?
Daniel
--
Edit this bug report at http://bugs.php.net/?id=21222&edit=1
#21226 [Ver]: function parse_url() fails
ID: 21226 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: *URL Functions Operating System: w2000 PHP Version: 4.3.0 Assigned To: iliaa New Comment: Add / after end of port part is a good solution. Thanks. Do you consider that it's a bug or parse_url is url RFC compliant ? Previous Comments: [2002-12-27 19:04:18] [EMAIL PROTECTED] Seems to come from 'port' part of url. If we consider this : user:password@host?foo works fine, user:password@host:port?foo fails but user:password@host?foo:port works and returns port number in $p_url[port] but it's not correct [2002-12-27 19:00:53] [EMAIL PROTECTED] Some more info: port has to be numeric and less than 5 digits long. The bug part seems to be that parse_url() doesn't recognize the end of port part if '/' is missing. So $url="http://user:[EMAIL PROTECTED]:80/?foo";; works as expected. [2002-12-27 18:49:37] [EMAIL PROTECTED] Verified on Windows and Linux ZTS builds. Assigning to Ilia. [2002-12-27 18:47:38] [EMAIL PROTECTED] Does not working on 4.3.0RC4 AND 4.3.0 final too [2002-12-27 18:35:38] [EMAIL PROTECTED] Script below : $url="http://user:[EMAIL PROTECTED]:portnumber?foo";; $p_url=parse_url($url); print_r($p_url); Fails with following output : Warning: parse_url(http://user:[EMAIL PROTECTED]:portnumber?foo) [function.parse-url]: Unable to parse url in C:\script\t.php on line 2 This function was working in php 4.2 It does not working with 4.3.0RC4 -- Edit this bug report at http://bugs.php.net/?id=21226&edit=1
#21226 [Ver]: function parse_url() fails
ID: 21226 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: *URL Functions Operating System: w2000 PHP Version: 4.3.0 Assigned To: iliaa New Comment: Seems to come from 'port' part of url. If we consider this : user:password@host?foo works fine, user:password@host:port?foo fails but user:password@host?foo:port works and returns port number in $p_url[port] but it's not correct Previous Comments: [2002-12-27 19:00:53] [EMAIL PROTECTED] Some more info: port has to be numeric and less than 5 digits long. The bug part seems to be that parse_url() doesn't recognize the end of port part if '/' is missing. So $url="http://user:[EMAIL PROTECTED]:80/?foo";; works as expected. [2002-12-27 18:49:37] [EMAIL PROTECTED] Verified on Windows and Linux ZTS builds. Assigning to Ilia. [2002-12-27 18:47:38] [EMAIL PROTECTED] Does not working on 4.3.0RC4 AND 4.3.0 final too [2002-12-27 18:35:38] [EMAIL PROTECTED] Script below : $url="http://user:[EMAIL PROTECTED]:portnumber?foo";; $p_url=parse_url($url); print_r($p_url); Fails with following output : Warning: parse_url(http://user:[EMAIL PROTECTED]:portnumber?foo) [function.parse-url]: Unable to parse url in C:\script\t.php on line 2 This function was working in php 4.2 It does not working with 4.3.0RC4 -- Edit this bug report at http://bugs.php.net/?id=21226&edit=1
#21226 [Ver]: function parse_url() fails
ID: 21226 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: *URL Functions Operating System: w2000 PHP Version: 4.3.0 Assigned To: iliaa New Comment: Some more info: port has to be numeric and less than 5 digits long. The bug part seems to be that parse_url() doesn't recognize the end of port part if '/' is missing. So $url="http://user:[EMAIL PROTECTED]:80/?foo";; works as expected. Previous Comments: [2002-12-27 18:49:37] [EMAIL PROTECTED] Verified on Windows and Linux ZTS builds. Assigning to Ilia. [2002-12-27 18:47:38] [EMAIL PROTECTED] Does not working on 4.3.0RC4 AND 4.3.0 final too [2002-12-27 18:35:38] [EMAIL PROTECTED] Script below : $url="http://user:[EMAIL PROTECTED]:portnumber?foo";; $p_url=parse_url($url); print_r($p_url); Fails with following output : Warning: parse_url(http://user:[EMAIL PROTECTED]:portnumber?foo) [function.parse-url]: Unable to parse url in C:\script\t.php on line 2 This function was working in php 4.2 It does not working with 4.3.0RC4 -- Edit this bug report at http://bugs.php.net/?id=21226&edit=1
#21226 [Opn->Ver]: function parse_url() fails
ID: 21226 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified Bug Type: *URL Functions Operating System: w2000 PHP Version: 4.3.0 -Assigned To: +Assigned To: iliaa New Comment: Verified on Windows and Linux ZTS builds. Assigning to Ilia. Previous Comments: [2002-12-27 18:47:38] [EMAIL PROTECTED] Does not working on 4.3.0RC4 AND 4.3.0 final too [2002-12-27 18:35:38] [EMAIL PROTECTED] Script below : $url="http://user:[EMAIL PROTECTED]:portnumber?foo";; $p_url=parse_url($url); print_r($p_url); Fails with following output : Warning: parse_url(http://user:[EMAIL PROTECTED]:portnumber?foo) [function.parse-url]: Unable to parse url in C:\script\t.php on line 2 This function was working in php 4.2 It does not working with 4.3.0RC4 -- Edit this bug report at http://bugs.php.net/?id=21226&edit=1
#21226 [Opn]: function parse_url() fails
ID: 21226 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *URL Functions Operating System: w2000 PHP Version: 4.3.0 New Comment: Does not working on 4.3.0RC4 AND 4.3.0 final too Previous Comments: [2002-12-27 18:35:38] [EMAIL PROTECTED] Script below : $url="http://user:[EMAIL PROTECTED]:portnumber?foo";; $p_url=parse_url($url); print_r($p_url); Fails with following output : Warning: parse_url(http://user:[EMAIL PROTECTED]:portnumber?foo) [function.parse-url]: Unable to parse url in C:\script\t.php on line 2 This function was working in php 4.2 It does not working with 4.3.0RC4 -- Edit this bug report at http://bugs.php.net/?id=21226&edit=1
#21226 [NEW]: function parse_url() fails
From: [EMAIL PROTECTED] Operating system: w2000 PHP version: 4.3.0 PHP Bug Type: *URL Functions Bug description: function parse_url() fails Script below : $url="http://user:[EMAIL PROTECTED]:portnumber?foo";; $p_url=parse_url($url); print_r($p_url); Fails with following output : Warning: parse_url(http://user:[EMAIL PROTECTED]:portnumber?foo) [function.parse-url]: Unable to parse url in C:\script\t.php on line 2 This function was working in php 4.2 It does not working with 4.3.0RC4 -- Edit bug report at http://bugs.php.net/?id=21226&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21226&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21226&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21226&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21226&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21226&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21226&r=support Expected behavior: http://bugs.php.net/fix.php?id=21226&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21226&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21226&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21226&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21226&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21226&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21226&r=isapi
#21223 [Opn->Bgs]: Compile dies
ID: 21223 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: RH Linux 8.0 PHP Version: 4.3.0 New Comment: I humbly apologize! "make install" works and it seems that all is well, except GD 2.0.8 doesn't seem to be playing well, but that's not your problem. Thanks for a great product! Previous Comments: [2002-12-27 17:07:36] [EMAIL PROTECTED] Previous release compiles never just ended that quickly. Is it safe to try a "make install"? [2002-12-27 17:04:39] [EMAIL PROTECTED] But what makes you think it isn't simply done? I don't see any errors here. Did you try running it? [2002-12-27 17:03:27] [EMAIL PROTECTED] Correction to my last comment. That last line is actually sapi/cli/php - not api/cli/php. [2002-12-27 17:01:26] [EMAIL PROTECTED] It just stops and the command line appears. Here are the last few lines of the "make" command on the screen. I hesitated to try "make install" for fear of messing up my current installation. sapi/cli/php_cli.so sapi/cli/getopt.lo main/internal_functions_cli.lo -lmysqlclient -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -o api/cli/php [root@localhost php-4.3.0]# I have also tried compiling with only the mysql and apx options to rule out the other packages and it still stops. [2002-12-27 16:53:59] [EMAIL PROTECTED] Are you sure your compile fails? Does "make install" work? If no, please post a last few lines of the make output. 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/21223 -- Edit this bug report at http://bugs.php.net/?id=21223&edit=1
#21223 [Fbk->Opn]: Compile dies
ID: 21223 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: RH Linux 8.0 PHP Version: 4.3.0 New Comment: Previous release compiles never just ended that quickly. Is it safe to try a "make install"? Previous Comments: [2002-12-27 17:04:39] [EMAIL PROTECTED] But what makes you think it isn't simply done? I don't see any errors here. Did you try running it? [2002-12-27 17:03:27] [EMAIL PROTECTED] Correction to my last comment. That last line is actually sapi/cli/php - not api/cli/php. [2002-12-27 17:01:26] [EMAIL PROTECTED] It just stops and the command line appears. Here are the last few lines of the "make" command on the screen. I hesitated to try "make install" for fear of messing up my current installation. sapi/cli/php_cli.so sapi/cli/getopt.lo main/internal_functions_cli.lo -lmysqlclient -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -o api/cli/php [root@localhost php-4.3.0]# I have also tried compiling with only the mysql and apx options to rule out the other packages and it still stops. [2002-12-27 16:53:59] [EMAIL PROTECTED] Are you sure your compile fails? Does "make install" work? If no, please post a last few lines of the make output. [2002-12-27 16:36:18] [EMAIL PROTECTED] When I try to compile v4.3.0, it goes awhile and then just dies. Here is the config line: ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs --enable-sockets --with-gd=/usr/local --enable-gd-native-ttf --with-ttf --with-zlib --with-exif --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local/jpeg-6b --with-png-dir=/usr/local --with-t1lib Here are the last few lines of the config.log: configure:81224: gcc -o conftest -g -O2 -DLINUX=22 -DUSE_HSREGEX conftest.c 1>&5 /tmp/ccnwQBmi.o: In function `main': /opt/php-4.3.0/configure:81210: undefined reference to `dlopen' /opt/php-4.3.0/configure:81215: undefined reference to `dlsym' /opt/php-4.3.0/configure:81216: undefined reference to `dlsym' collect2: ld returned 1 exit status configure:81307: checking whether to enable thread-safety configure:81311: checking whether to enable inline optimization for GCC configure:81315: checking whether to enable a memory limit configure:81319: checking whether to enable Zend debugging configure:81323: checking whether to enable Zend multibyte configure:81386: checking for inline configure:81463: checking for stdarg.h configure:82745: checking for working mkdir -p -- Edit this bug report at http://bugs.php.net/?id=21223&edit=1
#21223 [Opn->Fbk]: Compile dies
ID: 21223 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: RH Linux 8.0 PHP Version: 4.3.0 New Comment: But what makes you think it isn't simply done? I don't see any errors here. Did you try running it? Previous Comments: [2002-12-27 17:03:27] [EMAIL PROTECTED] Correction to my last comment. That last line is actually sapi/cli/php - not api/cli/php. [2002-12-27 17:01:26] [EMAIL PROTECTED] It just stops and the command line appears. Here are the last few lines of the "make" command on the screen. I hesitated to try "make install" for fear of messing up my current installation. sapi/cli/php_cli.so sapi/cli/getopt.lo main/internal_functions_cli.lo -lmysqlclient -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -o api/cli/php [root@localhost php-4.3.0]# I have also tried compiling with only the mysql and apx options to rule out the other packages and it still stops. [2002-12-27 16:53:59] [EMAIL PROTECTED] Are you sure your compile fails? Does "make install" work? If no, please post a last few lines of the make output. [2002-12-27 16:36:18] [EMAIL PROTECTED] When I try to compile v4.3.0, it goes awhile and then just dies. Here is the config line: ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs --enable-sockets --with-gd=/usr/local --enable-gd-native-ttf --with-ttf --with-zlib --with-exif --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local/jpeg-6b --with-png-dir=/usr/local --with-t1lib Here are the last few lines of the config.log: configure:81224: gcc -o conftest -g -O2 -DLINUX=22 -DUSE_HSREGEX conftest.c 1>&5 /tmp/ccnwQBmi.o: In function `main': /opt/php-4.3.0/configure:81210: undefined reference to `dlopen' /opt/php-4.3.0/configure:81215: undefined reference to `dlsym' /opt/php-4.3.0/configure:81216: undefined reference to `dlsym' collect2: ld returned 1 exit status configure:81307: checking whether to enable thread-safety configure:81311: checking whether to enable inline optimization for GCC configure:81315: checking whether to enable a memory limit configure:81319: checking whether to enable Zend debugging configure:81323: checking whether to enable Zend multibyte configure:81386: checking for inline configure:81463: checking for stdarg.h configure:82745: checking for working mkdir -p -- Edit this bug report at http://bugs.php.net/?id=21223&edit=1
#21223 [Opn]: Compile dies
ID: 21223 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: RH Linux 8.0 PHP Version: 4.3.0 New Comment: Correction to my last comment. That last line is actually sapi/cli/php - not api/cli/php. Previous Comments: [2002-12-27 17:01:26] [EMAIL PROTECTED] It just stops and the command line appears. Here are the last few lines of the "make" command on the screen. I hesitated to try "make install" for fear of messing up my current installation. sapi/cli/php_cli.so sapi/cli/getopt.lo main/internal_functions_cli.lo -lmysqlclient -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -o api/cli/php [root@localhost php-4.3.0]# I have also tried compiling with only the mysql and apx options to rule out the other packages and it still stops. [2002-12-27 16:53:59] [EMAIL PROTECTED] Are you sure your compile fails? Does "make install" work? If no, please post a last few lines of the make output. [2002-12-27 16:36:18] [EMAIL PROTECTED] When I try to compile v4.3.0, it goes awhile and then just dies. Here is the config line: ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs --enable-sockets --with-gd=/usr/local --enable-gd-native-ttf --with-ttf --with-zlib --with-exif --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local/jpeg-6b --with-png-dir=/usr/local --with-t1lib Here are the last few lines of the config.log: configure:81224: gcc -o conftest -g -O2 -DLINUX=22 -DUSE_HSREGEX conftest.c 1>&5 /tmp/ccnwQBmi.o: In function `main': /opt/php-4.3.0/configure:81210: undefined reference to `dlopen' /opt/php-4.3.0/configure:81215: undefined reference to `dlsym' /opt/php-4.3.0/configure:81216: undefined reference to `dlsym' collect2: ld returned 1 exit status configure:81307: checking whether to enable thread-safety configure:81311: checking whether to enable inline optimization for GCC configure:81315: checking whether to enable a memory limit configure:81319: checking whether to enable Zend debugging configure:81323: checking whether to enable Zend multibyte configure:81386: checking for inline configure:81463: checking for stdarg.h configure:82745: checking for working mkdir -p -- Edit this bug report at http://bugs.php.net/?id=21223&edit=1
#21223 [Fbk->Opn]: Compile dies
ID: 21223 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: RH Linux 8.0 PHP Version: 4.3.0 New Comment: It just stops and the command line appears. Here are the last few lines of the "make" command on the screen. I hesitated to try "make install" for fear of messing up my current installation. sapi/cli/php_cli.so sapi/cli/getopt.lo main/internal_functions_cli.lo -lmysqlclient -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -o api/cli/php [root@localhost php-4.3.0]# I have also tried compiling with only the mysql and apx options to rule out the other packages and it still stops. Previous Comments: [2002-12-27 16:53:59] [EMAIL PROTECTED] Are you sure your compile fails? Does "make install" work? If no, please post a last few lines of the make output. [2002-12-27 16:36:18] [EMAIL PROTECTED] When I try to compile v4.3.0, it goes awhile and then just dies. Here is the config line: ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs --enable-sockets --with-gd=/usr/local --enable-gd-native-ttf --with-ttf --with-zlib --with-exif --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local/jpeg-6b --with-png-dir=/usr/local --with-t1lib Here are the last few lines of the config.log: configure:81224: gcc -o conftest -g -O2 -DLINUX=22 -DUSE_HSREGEX conftest.c 1>&5 /tmp/ccnwQBmi.o: In function `main': /opt/php-4.3.0/configure:81210: undefined reference to `dlopen' /opt/php-4.3.0/configure:81215: undefined reference to `dlsym' /opt/php-4.3.0/configure:81216: undefined reference to `dlsym' collect2: ld returned 1 exit status configure:81307: checking whether to enable thread-safety configure:81311: checking whether to enable inline optimization for GCC configure:81315: checking whether to enable a memory limit configure:81319: checking whether to enable Zend debugging configure:81323: checking whether to enable Zend multibyte configure:81386: checking for inline configure:81463: checking for stdarg.h configure:82745: checking for working mkdir -p -- Edit this bug report at http://bugs.php.net/?id=21223&edit=1
#21224 [NEW]: apache configure fails at php module
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: apache configure fails at php module apache 1.3.27 configure script fails at this point: with gcc version 2.95.2 and GNU ld version 2.13 + doing sanity check on compiler and options ** A test compilation with your Makefile configuration ** failed. The below error output from the compilation ** test will give you an idea what is failing. Note that ** Apache requires an ANSI C Compiler, such as gcc. Error Output for sanity check make[1]: Entering directory `/usr/local/src/apache/apache_1.3.27/src/helpers' cd ..; gcc -O3 -DDYNAMIC_MODULE_LIMIT=0 -I/usr/local/include/mysql -DSOLARIS2=280 -DMOD_SSL=208111 -DEAPI -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` -L/usr/local/ssl/lib -o helpers/dummy helpers/dummy.c -L/usr/local/lib/mysql -lmysqlclient -R/usr/ucblib -R/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -R/usr/local/ssl/lib -R/usr/local/lib -R/opt/sfw/lib -R/usr/local/src/apache/imap-2002.RC5/c-client -R/usr/local/lib/mysql -L/usr/ucblib -L/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -L/usr/local/ssl/lib -L/usr/local/lib -L/opt/sfw/lib -L/usr/local/src/apache/imap-2002.RC5/c-client -L/usr/local/lib/mysql -Lmodules/php4 -L../modules/php4 -L../../modules/php4 -lmodphp4 -export-symbols /usr/local/src/apache/php-4.3.0/sapi/apache/php.sym -L/usr/ucblib -L/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -L/usr/local/ssl/lib -L/usr/local/lib -L/opt/sfw/lib -L/usr/local/src/apache/imap-2002.RC5/c-client -L/usr/local/lib/mysql -lc-client -lmm -lmysqlclient -lmcrypt -lltdl -lcrypt -lpam -lgd -lpng -lz -ljpeg -lgdbm -lcurl -lz -lcrypt -lssl -lcrypto -lresolv -lm -ldl -lnsl -lsocket -lgcc -lcrypt -lcurl -ldl -lsocket -lnsl -lsocket -lnsl -lpthread -lssl -lcrypto ld: fatal: file /usr/local/src/apache/php-4.3.0/sapi/apache/php.sym: unknown file type ld: fatal: File processing errors. No output written to helpers/dummy collect2: ld returned 1 exit status make[1]: *** [dummy] Error 1 make[1]: Leaving directory `/usr/local/src/apache/apache_1.3.27/src/helpers' = End of Error Report = -- Edit bug report at http://bugs.php.net/?id=21224&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21224&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21224&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21224&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21224&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21224&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21224&r=support Expected behavior: http://bugs.php.net/fix.php?id=21224&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21224&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21224&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21224&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21224&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21224&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21224&r=isapi
#21223 [Opn->Fbk]: Compile dies
ID: 21223 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: RH Linux 8.0 PHP Version: 4.3.0 New Comment: Are you sure your compile fails? Does "make install" work? If no, please post a last few lines of the make output. Previous Comments: [2002-12-27 16:36:18] [EMAIL PROTECTED] When I try to compile v4.3.0, it goes awhile and then just dies. Here is the config line: ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs --enable-sockets --with-gd=/usr/local --enable-gd-native-ttf --with-ttf --with-zlib --with-exif --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local/jpeg-6b --with-png-dir=/usr/local --with-t1lib Here are the last few lines of the config.log: configure:81224: gcc -o conftest -g -O2 -DLINUX=22 -DUSE_HSREGEX conftest.c 1>&5 /tmp/ccnwQBmi.o: In function `main': /opt/php-4.3.0/configure:81210: undefined reference to `dlopen' /opt/php-4.3.0/configure:81215: undefined reference to `dlsym' /opt/php-4.3.0/configure:81216: undefined reference to `dlsym' collect2: ld returned 1 exit status configure:81307: checking whether to enable thread-safety configure:81311: checking whether to enable inline optimization for GCC configure:81315: checking whether to enable a memory limit configure:81319: checking whether to enable Zend debugging configure:81323: checking whether to enable Zend multibyte configure:81386: checking for inline configure:81463: checking for stdarg.h configure:82745: checking for working mkdir -p -- Edit this bug report at http://bugs.php.net/?id=21223&edit=1
#21223 [NEW]: Compile dies
From: [EMAIL PROTECTED] Operating system: RH Linux 8.0 PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: Compile dies When I try to compile v4.3.0, it goes awhile and then just dies. Here is the config line: ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs --enable-sockets --with-gd=/usr/local --enable-gd-native-ttf --with-ttf --with-zlib --with-exif --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local/jpeg-6b --with-png-dir=/usr/local --with-t1lib Here are the last few lines of the config.log: configure:81224: gcc -o conftest -g -O2 -DLINUX=22 -DUSE_HSREGEX conftest.c 1>&5 /tmp/ccnwQBmi.o: In function `main': /opt/php-4.3.0/configure:81210: undefined reference to `dlopen' /opt/php-4.3.0/configure:81215: undefined reference to `dlsym' /opt/php-4.3.0/configure:81216: undefined reference to `dlsym' collect2: ld returned 1 exit status configure:81307: checking whether to enable thread-safety configure:81311: checking whether to enable inline optimization for GCC configure:81315: checking whether to enable a memory limit configure:81319: checking whether to enable Zend debugging configure:81323: checking whether to enable Zend multibyte configure:81386: checking for inline configure:81463: checking for stdarg.h configure:82745: checking for working mkdir -p -- Edit bug report at http://bugs.php.net/?id=21223&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21223&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21223&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21223&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21223&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21223&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21223&r=support Expected behavior: http://bugs.php.net/fix.php?id=21223&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21223&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21223&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21223&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21223&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21223&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21223&r=isapi
#21220 [Opn->Bgs]: Wrong Apache version in phpinfo() shown
ID: 21220 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: Windows 2000 Professional PHP Version: 4.3.0 New Comment: This is not a big. It simply shows the version of Apache php4apache.dll was compiled against. You can see you running apache version under SERVER_SOFTWARE. Previous Comments: [2002-12-27 14:21:25] [EMAIL PROTECTED] When executing a PHP script (*) on Apache 1.3.27 (PHP 4.3.0 as Apache module) it shows "Apache/1.3.24" as "Apache Version" while it should be 1.3.27. (*) -- Edit this bug report at http://bugs.php.net/?id=21220&edit=1
#21222 [Bgs]: problem with dirname
ID: 21222
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Directory function related
Operating System: Win2k
PHP Version: 4.3.0
New Comment:
No, the trailing / the docs talk about are cases where you actually
have a trailing / in the source path. eg. /some/path/
It does not mean that the trailing path of the returned string will be
stripped.
Previous Comments:
[2002-12-27 15:46:26] [EMAIL PROTECTED]
That reasoning doesn't quite go along with what the documentation says,
IMHO:
(quoted from http://www.php.net/dirname)
"[...]Essentially, this means that if there are no slashes in path , a
dot ('.') is returned, indicating the current directory. Otherwise, the
returned string is path with any trailing /component removed.[...]"
So for the input '/test.php', the first case (no slashes in path)
obviously doesn't apply, since there is a slash contained in the path
in question.
Now, the second case states that the returned string is the path
('/test.php') with any trailing /component (in this case '/test.php')
removed, i.e. simply ''.
So there seems to be some kind of contradiction between the manual and
what you said, could your elaborate on that, please? Apologies if I'm
missing the point,
Michael
PS: Even if the behaviour was changed to return '/' instead of an empty
string, the transformation of '/' to the default directory separator
should still be officially documented (and not in the user comments).
[2002-12-27 15:27:42] [EMAIL PROTECTED]
Your expectation is simply wrong. dirname() is documented to return
the directory component of a pathname you feed it. You fed it
/test.php and it gave you back / (or the Windows equivalent thereof) as
expected.`
[2002-12-27 15:24:46] [EMAIL PROTECTED]
Hi there,
';
echo '"' . dirname($_SERVER['REQUEST_URI']) . '"';
?>
produces following output...
/test.php
"\"
Instead of the output above, i expected
/test.php
""
Can someone confirm this?
Daniel
--
Edit this bug report at http://bugs.php.net/?id=21222&edit=1
#21222 [Com]: problem with dirname
ID: 21222
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Directory function related
Operating System: Win2k
PHP Version: 4.3.0
New Comment:
That reasoning doesn't quite go along with what the documentation says,
IMHO:
(quoted from http://www.php.net/dirname)
"[...]Essentially, this means that if there are no slashes in path , a
dot ('.') is returned, indicating the current directory. Otherwise, the
returned string is path with any trailing /component removed.[...]"
So for the input '/test.php', the first case (no slashes in path)
obviously doesn't apply, since there is a slash contained in the path
in question.
Now, the second case states that the returned string is the path
('/test.php') with any trailing /component (in this case '/test.php')
removed, i.e. simply ''.
So there seems to be some kind of contradiction between the manual and
what you said, could your elaborate on that, please? Apologies if I'm
missing the point,
Michael
PS: Even if the behaviour was changed to return '/' instead of an empty
string, the transformation of '/' to the default directory separator
should still be officially documented (and not in the user comments).
Previous Comments:
[2002-12-27 15:27:42] [EMAIL PROTECTED]
Your expectation is simply wrong. dirname() is documented to return
the directory component of a pathname you feed it. You fed it
/test.php and it gave you back / (or the Windows equivalent thereof) as
expected.`
[2002-12-27 15:24:46] [EMAIL PROTECTED]
Hi there,
';
echo '"' . dirname($_SERVER['REQUEST_URI']) . '"';
?>
produces following output...
/test.php
"\"
Instead of the output above, i expected
/test.php
""
Can someone confirm this?
Daniel
--
Edit this bug report at http://bugs.php.net/?id=21222&edit=1
#21222 [Opn->Bgs]: problem with dirname
ID: 21222 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Directory function related Operating System: Win2k PHP Version: 4.3.0 New Comment: Your expectation is simply wrong. dirname() is documented to return the directory component of a pathname you feed it. You fed it /test.php and it gave you back / (or the Windows equivalent thereof) as expected.` Previous Comments: [2002-12-27 15:24:46] [EMAIL PROTECTED] Hi there, '; echo '"' . dirname($_SERVER['REQUEST_URI']) . '"'; ?> produces following output... /test.php "\" Instead of the output above, i expected /test.php "" Can someone confirm this? Daniel -- Edit this bug report at http://bugs.php.net/?id=21222&edit=1
#21222 [NEW]: problem with dirname
From: [EMAIL PROTECTED] Operating system: Win2k PHP version: 4.3.0 PHP Bug Type: Directory function related Bug description: problem with dirname Hi there, '; echo '"' . dirname($_SERVER['REQUEST_URI']) . '"'; ?> produces following output... /test.php "\" Instead of the output above, i expected /test.php "" Can someone confirm this? Daniel -- Edit bug report at http://bugs.php.net/?id=21222&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21222&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21222&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21222&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21222&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21222&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21222&r=support Expected behavior: http://bugs.php.net/fix.php?id=21222&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21222&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21222&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21222&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21222&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21222&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21222&r=isapi
#19983 [Com]: Compile/Link failure w/Sablotron
ID: 19983 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: Mac OS X 10.2 PHP Version: 4.3.0-pre1 New Comment: Just got the first 4.3.0 release and cannot build under Solaris due to "line too long" when attempting make. That is followed, of course, with millions of undefined symbols. my configure: ./configure \ --with-apache=/apa/ \ --with-jpeg-dir=/usr/local \ --with-zlib-dir=/usr/local \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-gd \ --with-oci8=/export/home/orahome \ --enable-ftp \ --enable-sockets \ --with-pdflib \ --with-ming >configure.log 2>&1 & all goes fine until attempt "make" (both solaris and gnu makes same) NO DICE. Previous Comments: [2002-12-18 11:55:34] [EMAIL PROTECTED] The problem __really__ is, combining gcc3 and gcc2 suite, as outlined in this document: http://fink.sourceforge.net/doc/porting/preparing.php Secondly - if any warnings/errors occur as mentioned in the document above (libtool stuff), the links to patches for those are provided. PHP already has this covered. The following works: 1) configure expat, using gcc2 explicetely: CC=gcc2 \ ./configure \ --prefix=/your/prefix 2) configure libiconv, the same way: CC=gcc2 \ ./configure \ --prefix=/your/prefix 3) configure Sablotron (tested with 0.97RC2) using: CC=gcc2 \ CXX=g++2 \ ./configure \ --prefix=/your/prefix \ --with-expat-prefix=/your/prefix \ --with-iconv-prefix=/your/prefix PHP can then be configured, using: CC=gcc2 \ CXX=g++2 \ ./configure \ --prefix=/your/prefix \ --disable-cgi \ --enable-xslt \ --with-xslt-sablot=/your/prefix \ --with-expat-dir=/your/prefix \ --with-iconv-dir=/your/prefix I guess the same applies to gcc3, but you have to make sure, that all libs you include, are compiled with gcc3/g++3 then. [2002-12-17 13:57:23] [EMAIL PROTECTED] I don't think his workaround works... Putting the -lstdc++ on the end of the ZEND_EXTRA_LIBS variable enables everything to make, but I cannot make install and I certainly can't run with Apache... I get similar errors that [EMAIL PROTECTED] (above) gets. I know this is kind of a 'me too' response, but I want to emphasize that there is NO workaround. Thanks! During make install: Installing PHP CLI binary:/usr/local/bin/ Installing PEAR environment: /usr/local/lib/php/ dyld: /usr/local/src/build-php-4.3.0RC3/php-4.3.0RC3/sapi/ cli/php Undefined symbols: __ZTVN10__cxxabiv117__class_type_infoE __ZTVN10__cxxabiv120__si_class_type_infoE __ZdaPv __ZdlPv __Znwm ___gxx_personality_v0 __ZSt9terminatev __Znam __ZTVN10__cxxabiv121__vmi_class_type_infoE ___cxa_pure_virtual make[1]: *** [install-pear-installer] Trace/BPT trap make: *** [install-pear] Error 2 [2002-12-17 04:29:14] [EMAIL PROTECTED] As the original reporter provides a work-around, I'm re-opening this bug-report, and see if we're able to make some configure hack, that strips all instances of -lstdc++ and adds one to the end of the linking process. [2002-11-18 05:00:53] [EMAIL PROTECTED] make ./configure --prefix=/usr --with-apxs=/usr/sbin/apxs --mandir=/usr/share/man --infodir=/usr/share/info --with-config-file-path=/etc/httpd --enable-calendar --with-iconv=/usr/local --enable-exif --enable-ftp --enable-wddx --with-xml --with-zlib --with-curl=/usr --with-gd=/usr/local --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-imap=../imap-2002.RC10 --with-imap-ssl=/usr --enable-sablot --enable-sablot-errors-descriptive --enable-xslt --with-xslt-sablot=/usr/local --with-mcrypt=/usr/local --with-mhash=/usr/local --with-mysql=/usr/local/mysql --with-expat-dir=/usr/local modified ZEND_EXTRA_LIBS in Makefile before make make is ok but when I did sudo make install : dyld: /Users/benoitc/build/php-4.3.0RC1/sapi/cli/php Undefined symbols: __ZTVN10__cxxabiv117__class_type_infoE __ZTVN10__cxxabiv120__si_class_type_infoE __ZdaPv __ZdlPv __Znwm ___gxx_personality_v0 __ZSt9terminatev __Znam __ZTVN10__cxxabiv121__vmi_class_type_infoE ___cxa_pure_virtual make[1]: *** [install-pear-installer] Trace/BPT trap make: *** [install-pear] Error 2 [2002-10-27 19:48:58] [EMAIL PROTECTED] libtool 1.4.2 gcc 3.1 autoconf 2.5.something confirmed problem. Solution? None at this time, I'd like to open a dialog with an Apple rep about this. --
#21218 [Opn]: should be able to set a list of hidden environment vars
ID: 21218 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Red Hat Linux 7.3 PHP Version: 4.3.0 New Comment: Hm, I didn't even know you could do that. But I don't want to prevent accessing of environment variables, really just prevent access of some, or at the very least be able to only turn _ENV off for phpinfo(). Previous Comments: [2002-12-27 14:27:51] [EMAIL PROTECTED] On a related note fwiw, even if E is removed from the variables_order directive (so that $_ENV will not exist), one can still use getenv() to access the variables. [2002-12-27 13:55:14] [EMAIL PROTECTED] Currently, safe_mode_protected_env_vars can be set to disallow setting of specific environment variables. I propose an option to set a list of environment variables (possibly with wildcards, such as SUDO_*) that are completely hidden from PHP pages, and do not show up in phpinfo() (Since you can disable environment variables, but to hide _ENV globals, you would have to disable variable listing completely, which is not always good enough). Showing certain environment settings are a huge security risk, such as SUDO_UID and SUDO_USER if apache was started using sudo, as well as PWD, PATH, SSH_CONNECTION, etc. Disabling phpinfo() is not always a possibility, since it gives a lot of useful information to users. -- Edit this bug report at http://bugs.php.net/?id=21218&edit=1
#21221 [Opn->]: [String] == 0 always true
ID: 21221
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Won\'t fix
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 4CVS-2002-12-27 (stable)
New Comment:
This will not change. Ad you don't need to both cast and use === at
the same time. That is overkill. Just use ===
Previous Comments:
[2002-12-27 14:29:08] [EMAIL PROTECTED]
This is not so much a bug since it was put in intentionally, that's why
I stuck this in "Feature/Change Request".
The basic problem is that ("Bob" == 0) evaluates to TRUE, defying all
the logic which I've been raised with. I've tried to add this to the
comments section under the documentation for bools, but after an
exchange it was reccomended that I submit a Documentation Bug Report
instead. I do however believe that this requires the attention of more
than just documentation, so I'm submitting it here.
I've been told that the reason ("Bob" == 0) is TRUE is that "Bob" can't
be translated into a numeric representation to compare to, and so it is
converted to 0. By the logic of other programming languages, I would
expect 0 to be converted to a string, not the other way around (I have
since modified all my code to ((string)"Bob" === (string)0) ), but I
dont think such being different is a bug so I'm not complaining.
The problem is that I dont consider a string that has something in it
to be equal to zero. So here's what I propose: Add a new constant
"BLEEM" [to borrow from George Carlin], which evaluates as being a
number but does not == any number. Any string unable to be converted to
a logical number, besides the empty string, will be set to BLEEM, The
idea being that a string which is not a number should NEVER evaluate
true when asked "Is this string equal to this number?"
This may want to be held off until a major release, since it could
potentially break code.
--
Edit this bug report at http://bugs.php.net/?id=21221&edit=1
#21221 [NEW]: [String] == 0 always true
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4CVS-2002-12-27 (stable)
PHP Bug Type: Feature/Change Request
Bug description: [String] == 0 always true
This is not so much a bug since it was put in intentionally, that's why I
stuck this in "Feature/Change Request".
The basic problem is that ("Bob" == 0) evaluates to TRUE, defying all the
logic which I've been raised with. I've tried to add this to the comments
section under the documentation for bools, but after an exchange it was
reccomended that I submit a Documentation Bug Report instead. I do however
believe that this requires the attention of more than just documentation,
so I'm submitting it here.
I've been told that the reason ("Bob" == 0) is TRUE is that "Bob" can't be
translated into a numeric representation to compare to, and so it is
converted to 0. By the logic of other programming languages, I would
expect 0 to be converted to a string, not the other way around (I have
since modified all my code to ((string)"Bob" === (string)0) ), but I dont
think such being different is a bug so I'm not complaining.
The problem is that I dont consider a string that has something in it to
be equal to zero. So here's what I propose: Add a new constant "BLEEM" [to
borrow from George Carlin], which evaluates as being a number but does not
== any number. Any string unable to be converted to a logical number,
besides the empty string, will be set to BLEEM, The idea being that a
string which is not a number should NEVER evaluate true when asked "Is
this string equal to this number?"
This may want to be held off until a major release, since it could
potentially break code.
--
Edit bug report at http://bugs.php.net/?id=21221&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21221&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21221&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21221&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21221&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21221&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21221&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21221&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21221&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21221&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21221&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21221&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21221&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21221&r=isapi
#21218 [Opn]: should be able to set a list of hidden environment vars
ID: 21218 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Red Hat Linux 7.3 PHP Version: 4.3.0 New Comment: On a related note fwiw, even if E is removed from the variables_order directive (so that $_ENV will not exist), one can still use getenv() to access the variables. Previous Comments: [2002-12-27 13:55:14] [EMAIL PROTECTED] Currently, safe_mode_protected_env_vars can be set to disallow setting of specific environment variables. I propose an option to set a list of environment variables (possibly with wildcards, such as SUDO_*) that are completely hidden from PHP pages, and do not show up in phpinfo() (Since you can disable environment variables, but to hide _ENV globals, you would have to disable variable listing completely, which is not always good enough). Showing certain environment settings are a huge security risk, such as SUDO_UID and SUDO_USER if apache was started using sudo, as well as PWD, PATH, SSH_CONNECTION, etc. Disabling phpinfo() is not always a possibility, since it gives a lot of useful information to users. -- Edit this bug report at http://bugs.php.net/?id=21218&edit=1
#15333 [NoF->Csd]: strndup access violation
ID: 15333 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Closed Bug Type: IIS related Operating System: Windows 2000 Pro PHP Version: 4.3.0-dev New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2002-12-27 14:13:05] [EMAIL PROTECTED] Whatever the fix was, it seems to have done the job! I have only done about 10 minutes of testing but so far ISAPI is working. [2002-12-26 09:11:51] [EMAIL PROTECTED] [Continued from my previous post] ...I forgot to add that setting the IIS Security to Low (IIS Process) allowed me to view more pages in the Attachment Mod of PHPBB2, but any time I tried to view a posting, even the first time, I would receive an AV. [2002-12-26 09:06:41] [EMAIL PROTECTED] I too have experienced this problem. I installed PHP4.2.3 on XP using ISAPI and PHPBB2.0.3. Everything worked fine and I was quite excited about my budding relationship with PHP when... I installed the PHPBB Attachment Mod 2.3.4 (www.opentools.de/attach_mod/) and then I would notice RAM utilization would max out, heavy disk thrashing, and then ~30s later an AV crash. Hope this helps. [2002-12-24 01:00:02] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-12-08 17:32:41] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip There was patch commited to the CVS on 2002/12/02 that may have solved the problem. 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/15333 -- Edit this bug report at http://bugs.php.net/?id=15333&edit=1
#21219 [Bgs]: LS_COLOR destruct phpinfo() Output
ID: 21219 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *General Issues Operating System: Linux Suse 8.0 PHP Version: 4.3.0 New Comment: Btw, this is related to the open feature request here: http://bugs.php.net/bug.php?id=5301 Previous Comments: [2002-12-27 14:14:26] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php word wrapping enviroment variables may corrupt them, therefor they are displayed as is. [2002-12-27 14:13:02] [EMAIL PROTECTED] If I open my file phpinfo.php for my phpinfos (phpinfo()) in Enviroment->LS_COLORS and PHP Variables->LS_COLORS it doesn't wordwrap the line, so it creates a very large cell with this value: no=00:fi=00:di=01;34:ln=01:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:ex=01;31:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tbz2=00;31:*.png=01;35:*.bmp=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.pcx=01;35:*.ppm=01;35:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.wav=00;32:*.mp3=00;32:*.au=00;32:*.aiff=00;32:*.mid=00;32:*.voc=00;32: Maybe this is only depend on the Browser (I'm using Opera 6.03) -- Edit this bug report at http://bugs.php.net/?id=21219&edit=1
#21220 [NEW]: Wrong Apache version in phpinfo() shown
From: [EMAIL PROTECTED] Operating system: Windows 2000 Professional PHP version: 4.3.0 PHP Bug Type: Apache related Bug description: Wrong Apache version in phpinfo() shown When executing a PHP script (*) on Apache 1.3.27 (PHP 4.3.0 as Apache module) it shows "Apache/1.3.24" as "Apache Version" while it should be 1.3.27. (*) -- Edit bug report at http://bugs.php.net/?id=21220&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21220&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21220&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21220&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21220&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21220&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21220&r=support Expected behavior: http://bugs.php.net/fix.php?id=21220&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21220&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21220&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21220&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21220&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21220&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21220&r=isapi
#21219 [Opn->Bgs]: LS_COLOR destruct phpinfo() Output
ID: 21219 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Linux Suse 8.0 PHP Version: 4.3.0 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 word wrapping enviroment variables may corrupt them, therefor they are displayed as is. Previous Comments: [2002-12-27 14:13:02] [EMAIL PROTECTED] If I open my file phpinfo.php for my phpinfos (phpinfo()) in Enviroment->LS_COLORS and PHP Variables->LS_COLORS it doesn't wordwrap the line, so it creates a very large cell with this value: no=00:fi=00:di=01;34:ln=01:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:ex=01;31:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tbz2=00;31:*.png=01;35:*.bmp=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.pcx=01;35:*.ppm=01;35:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.wav=00;32:*.mp3=00;32:*.au=00;32:*.aiff=00;32:*.mid=00;32:*.voc=00;32: Maybe this is only depend on the Browser (I'm using Opera 6.03) -- Edit this bug report at http://bugs.php.net/?id=21219&edit=1
#17098 [Ana->Csd]: apache sending 304 - not modified header
ID: 17098
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Analyzed
+Status: Closed
Bug Type: Apache2 related
Operating System: linux
PHP Version: 4.0CVS-2002-10-17
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2002-12-27 13:55:15] [EMAIL PROTECTED]
... and the bug is present in 4.3.0 release.
[2002-12-25 18:03:55] [EMAIL PROTECTED]
... and it's not fixed in 4.3.0 RC4 either...
Daniel
[2002-12-13 18:24:22] [EMAIL PROTECTED]
This bug is _NOT_ fixed in 4.3.0 rc3!
In 4.3.0, the apache2 support should not be experimental anymore, so I
think, this is a real showstopper IMHO.
I think, it's time to fix this issue now, it's so annoying and
unneccessary. If this patch has any known drawbacks that I'm not aware
of, then it's NOT the correct solution to simply ignore this subject as
whole.
Daniel
Here is the patch again as diff against php 4.3.0 rc 3:
--- sapi/apache2filter/sapi_apache2.c.old Thu Dec 12 21:48:58
2002
+++ sapi/apache2filter/sapi_apache2.c Thu Dec 12 21:50:43 2002
@@ -619,14 +619,24 @@
return OK;
}
+static int includes_setup(ap_filter_t *f)
+{
+/* We will ALWAYS set the no_local_copy value to 1 so
+ * that we will not send 304s.
+ */
+f->r->no_local_copy = 1;
+
+return OK;
+}
+
static void php_register_hook(apr_pool_t *p)
{
ap_hook_pre_config(php_pre_config, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_config(php_apache_server_startup, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_insert_filter(php_insert_filter, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_read_request(php_post_read_request, NULL, NULL,
APR_HOOK_MIDDLE);
- ap_register_output_filter("PHP", php_output_filter, NULL,
AP_FTYPE_RESOURCE);
- ap_register_input_filter("PHP", php_input_filter, NULL,
AP_FTYPE_RESOURCE);
+ ap_register_output_filter("PHP", php_output_filter,
includes_setup, AP_FTYPE_RESOURCE);
+ ap_register_input_filter("PHP", php_input_filter,
includes_setup, AP_FTYPE_RESOURCE);
}
AP_MODULE_DECLARE_DATA module php4_module = {
[2002-12-03 09:28:16] [EMAIL PROTECTED]
Maybe I missed something. What patch? Is this still a php bug? I
have Apache 2.0.40 and php-4.4-2.
[2002-10-18 06:34:46] [EMAIL PROTECTED]
I tried a patch submited by [EMAIL PROTECTED]
and it seems to solve the problem. I don't know to what extent, but the
logic of it seems ok to me...
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/17098
--
Edit this bug report at http://bugs.php.net/?id=17098&edit=1
#15333 [Com]: strndup access violation
ID: 15333 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: IIS related Operating System: Windows 2000 Pro PHP Version: 4.3.0-dev New Comment: Whatever the fix was, it seems to have done the job! I have only done about 10 minutes of testing but so far ISAPI is working. Previous Comments: [2002-12-26 09:11:51] [EMAIL PROTECTED] [Continued from my previous post] ...I forgot to add that setting the IIS Security to Low (IIS Process) allowed me to view more pages in the Attachment Mod of PHPBB2, but any time I tried to view a posting, even the first time, I would receive an AV. [2002-12-26 09:06:41] [EMAIL PROTECTED] I too have experienced this problem. I installed PHP4.2.3 on XP using ISAPI and PHPBB2.0.3. Everything worked fine and I was quite excited about my budding relationship with PHP when... I installed the PHPBB Attachment Mod 2.3.4 (www.opentools.de/attach_mod/) and then I would notice RAM utilization would max out, heavy disk thrashing, and then ~30s later an AV crash. Hope this helps. [2002-12-24 01:00:02] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-12-08 17:32:41] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip There was patch commited to the CVS on 2002/12/02 that may have solved the problem. [2002-12-01 16:19:51] [EMAIL PROTECTED] I can easily reproduce this. With a simple 5 refreshes kills PHP and inetinfo. I have narrowed it down to a auto_prepend_file setting in php.ini. With that setting disabled then I cannot crash it. Hope this helps. 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/15333 -- Edit this bug report at http://bugs.php.net/?id=15333&edit=1
#21219 [NEW]: LS_COLOR destruct phpinfo() Output
From: [EMAIL PROTECTED] Operating system: Linux Suse 8.0 PHP version: 4.3.0 PHP Bug Type: *General Issues Bug description: LS_COLOR destruct phpinfo() Output If I open my file phpinfo.php for my phpinfos (phpinfo()) in Enviroment->LS_COLORS and PHP Variables->LS_COLORS it doesn't wordwrap the line, so it creates a very large cell with this value: no=00:fi=00:di=01;34:ln=01:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:ex=01;31:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tbz2=00;31:*.png=01;35:*.bmp=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.pcx=01;35:*.ppm=01;35:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.wav=00;32:*.mp3=00;32:*.au=00;32:*.aiff=00;32:*.mid=00;32:*.voc=00;32: Maybe this is only depend on the Browser (I'm using Opera 6.03) -- Edit bug report at http://bugs.php.net/?id=21219&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21219&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21219&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21219&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21219&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21219&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21219&r=support Expected behavior: http://bugs.php.net/fix.php?id=21219&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21219&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21219&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21219&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21219&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21219&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21219&r=isapi
#21217 [Opn->Bgs]: Having problem with local php_flag
ID: 21217 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: RedHat Linux 8 PHP Version: 4.3.0 New Comment: Not a bug, use 1 and 0 instead of On and Off. Previous Comments: [2002-12-27 13:19:16] [EMAIL PROTECTED] Hi there ! I have created a .htaccess to set my register_globals to Off and it looks as below php_flag magic_quotes_gpc On php_flag register_globals Off I still can see that (with phpmyadmin) both Master and Local values are On. I vae tried the same configuration with NetWare 6(+SP2) runninh Apache 2.0.43 WebServer with PHP 4.2.4-dev with the same result. Thanking in advance. PS : I know that I can try to set php_flag in httpd.conf as well, I prefer using .htaccess -- Edit this bug report at http://bugs.php.net/?id=21217&edit=1
#17098 [Com]: apache sending 304 - not modified header
ID: 17098
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Apache2 related
Operating System: linux
PHP Version: 4.0CVS-2002-10-17
New Comment:
... and the bug is present in 4.3.0 release.
Previous Comments:
[2002-12-25 18:03:55] [EMAIL PROTECTED]
... and it's not fixed in 4.3.0 RC4 either...
Daniel
[2002-12-13 18:24:22] [EMAIL PROTECTED]
This bug is _NOT_ fixed in 4.3.0 rc3!
In 4.3.0, the apache2 support should not be experimental anymore, so I
think, this is a real showstopper IMHO.
I think, it's time to fix this issue now, it's so annoying and
unneccessary. If this patch has any known drawbacks that I'm not aware
of, then it's NOT the correct solution to simply ignore this subject as
whole.
Daniel
Here is the patch again as diff against php 4.3.0 rc 3:
--- sapi/apache2filter/sapi_apache2.c.old Thu Dec 12 21:48:58
2002
+++ sapi/apache2filter/sapi_apache2.c Thu Dec 12 21:50:43 2002
@@ -619,14 +619,24 @@
return OK;
}
+static int includes_setup(ap_filter_t *f)
+{
+/* We will ALWAYS set the no_local_copy value to 1 so
+ * that we will not send 304s.
+ */
+f->r->no_local_copy = 1;
+
+return OK;
+}
+
static void php_register_hook(apr_pool_t *p)
{
ap_hook_pre_config(php_pre_config, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_config(php_apache_server_startup, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_insert_filter(php_insert_filter, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_read_request(php_post_read_request, NULL, NULL,
APR_HOOK_MIDDLE);
- ap_register_output_filter("PHP", php_output_filter, NULL,
AP_FTYPE_RESOURCE);
- ap_register_input_filter("PHP", php_input_filter, NULL,
AP_FTYPE_RESOURCE);
+ ap_register_output_filter("PHP", php_output_filter,
includes_setup, AP_FTYPE_RESOURCE);
+ ap_register_input_filter("PHP", php_input_filter,
includes_setup, AP_FTYPE_RESOURCE);
}
AP_MODULE_DECLARE_DATA module php4_module = {
[2002-12-03 09:28:16] [EMAIL PROTECTED]
Maybe I missed something. What patch? Is this still a php bug? I
have Apache 2.0.40 and php-4.4-2.
[2002-10-18 06:34:46] [EMAIL PROTECTED]
I tried a patch submited by [EMAIL PROTECTED]
and it seems to solve the problem. I don't know to what extent, but the
logic of it seems ok to me...
[2002-10-18 05:43:08] [EMAIL PROTECTED]
Ok. We should do something about this bug, I suppose.
Mail from Ryou Takagi
= BEGIN
Yasuo Ohgaki wrote:
> Ilia A. wrote:
> >>Summary: Apache2 sending 304 - not modified header
> >>http://bugs.php.net/bug.php?id=17098
> >>
> >>This is serious problem for serious sites.
> >>(Serious sites shouldn't use Apache2, though)
> >
> >
> > This looks like an Apache 2 bug, rather then aPHP one. I am
guessing the fix
> > they made did not work properly.
>
> Great!
> Then we can just wait their fix :)
I am afraid this is not the case. This is the report of the status.
As from Apache 2.0.40, the API of the filter registration functions
has changed. The changelog says:
--- From Apache Changelog: in section "Changes with Apache 2.0.40" ---
*) Add a filter_init parameter to the filter registration functions
so that a filter can execute arbitrary code before the handlers
are invoked. This resolves a problem where mod_include requests
would incorrectly return a 304. [Justin Erenkrantz]
--- End quotation from Apache Changelog ---
And the current mod_include.c in Apache 2.0.43 source tree uses this
API like this:
--- From modules/filters/mod_include.c in Apache 2.0.43 source tree
---
static int includes_setup(ap_filter_t *f)
{
include_dir_config *conf =
(include_dir_config
*)ap_get_module_config(f->r->per_dir_config,
&include_module);
/* When our xbithack value isn't set to full or our platform isn't
* providing group-level protection bits or our group-level bits do
not
* have group-execite on, we will set the no_local_copy value to 1
so
* that we will not send 304s.
*/
if ((*conf->xbithack != xbithack_full)
|| !(f->r->finfo.valid & APR_FINFO_GPROT)
|| !(f->r->finfo.protection & APR_GEXECUTE)) {
f->r->no_local_copy = 1;
}
return OK;
}
/* Note from TAKAGI: several lines omitted */
static void register_hooks(apr_pool_t *p)
{
APR_REGISTER_OPTIONAL_FN(ap_ssi_get_tag_and_value);
APR_REGISTER_OPTIONA
#21218 [NEW]: should be able to set a list of hidden environment vars
From: [EMAIL PROTECTED] Operating system: Red Hat Linux 7.3 PHP version: 4.3.0 PHP Bug Type: Feature/Change Request Bug description: should be able to set a list of hidden environment vars Currently, safe_mode_protected_env_vars can be set to disallow setting of specific environment variables. I propose an option to set a list of environment variables (possibly with wildcards, such as SUDO_*) that are completely hidden from PHP pages, and do not show up in phpinfo() (Since you can disable environment variables, but to hide _ENV globals, you would have to disable variable listing completely, which is not always good enough). Showing certain environment settings are a huge security risk, such as SUDO_UID and SUDO_USER if apache was started using sudo, as well as PWD, PATH, SSH_CONNECTION, etc. Disabling phpinfo() is not always a possibility, since it gives a lot of useful information to users. -- Edit bug report at http://bugs.php.net/?id=21218&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21218&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21218&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21218&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21218&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21218&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21218&r=support Expected behavior: http://bugs.php.net/fix.php?id=21218&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21218&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21218&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21218&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21218&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21218&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21218&r=isapi
#21217 [NEW]: Having problem with local php_flag
From: [EMAIL PROTECTED] Operating system: RedHat Linux 8 PHP version: 4.3.0 PHP Bug Type: Apache related Bug description: Having problem with local php_flag Hi there ! I have created a .htaccess to set my register_globals to Off and it looks as below php_flag magic_quotes_gpc On php_flag register_globals Off I still can see that (with phpmyadmin) both Master and Local values are On. I vae tried the same configuration with NetWare 6(+SP2) runninh Apache 2.0.43 WebServer with PHP 4.2.4-dev with the same result. Thanking in advance. PS : I know that I can try to set php_flag in httpd.conf as well, I prefer using .htaccess -- Edit bug report at http://bugs.php.net/?id=21217&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21217&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21217&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21217&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21217&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21217&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21217&r=support Expected behavior: http://bugs.php.net/fix.php?id=21217&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21217&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21217&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21217&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21217&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21217&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21217&r=isapi
#21199 [Opn]: errors are output to the Apache error log as well as the page
ID: 21199 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Output Control Operating System: Red Hat Linux 7.3 -PHP Version: 4.3.0RC4 +PHP Version: 4.3.0 New Comment: This still happens in 4.3.0. Previous Comments: [2002-12-26 10:40:49] [EMAIL PROTECTED] Whenever a PHP error is output, the error seems to be output to both the page and the global Apache error log. Under normal circumstances I wouldn't consider this a problem, but for virtualhosts it is useless because the error does not go to their virtualhost-specific error log. Some examples of errors output: /home/eurasianconcepts/public_html/car_gallery.php(62) : Warning - getimagesize() [function.getimagesize]: Read error! /home/wtfiml33t/public_html/viewarticle.php(11) : Warning - mysql_result() [function.mysql-result]: Unable to jump to row 0 on MySQL result index 12 display_errors is ON, log_errors is OFF, and track_errors is OFF. -- Edit this bug report at http://bugs.php.net/?id=21199&edit=1
#21216 [Opn->]: phpize passes --no-verify to ltconfig without specifying host
ID: 21216 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Won\'t fix Bug Type: *Configuration Issues Operating System: FreeBSD 4.7-STABLE PHP Version: 4.3.0 New Comment: PHP requires libtool 1.4 anyway, so the best thing would be to mail the FreeBSD maintainers again to update their software. Derick Previous Comments: [2002-12-27 11:25:58] [EMAIL PROTECTED] The phpize program creates a configure file that executes ltconfig with --no-verify but does not specify the host, FreeBSD ltconfig (libtool 1.3.4) requires the host be specified when the --no-verify parameter is passed, this results in the configure failing. When libtool 1.4 is installed the problem is resolved however 1.3.4 is what is in FreeBSD ports. This has been verified to be true with PHP 4.3.0 release on FreeBSD 4.7-STABLE with at least the curl, mhash and bz2 extensions. My configuration is as follows: AMD Athlon 1 GHZ CPU (686 class) FreeBSD 4.7 256 MB RAM Apache 1.3.27 PHP 4.3.0 Libtool: (GNU libtool) 1.3.4-freebsd-ports My PHP configuration line is: './configure' '--with-apxs=/usr/local/sbin/apxs' '--with-mcrypt' '--with-mhash' '--with-zlib' '--with-bz2' '--with-interbase' '--with-pdflib' '--with-gd' '--with-pgsql' '--with-mysql' '--enable-ftp' The output from the failed configure script is: loading cache /dev/null within ltconfig ltconfig: you must specify a host type if you use `--no-verify' Try `ltconfig --help' for more information. configure: error: libtool configure fail I manually installed libtool 1.4 and the problem went away, however the version of libtool in the FreeBSD ports collection is 1.3.4 so it is what most FreeBSD users will have installed. -- Edit this bug report at http://bugs.php.net/?id=21216&edit=1
#21189 [Com]: TTF output function frose Apache
ID: 21189 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: windows 2000/sp3 PHP Version: 4.3.0RC4 New Comment: I have problems too, the same OS (Win2k sp3) with php_gd.dll and php_gd2.dll and php 4.2.3 & php 4.3.0RC4 php installed as an Apache 1.3.24 module I use the gd only to produce small png, and i get error using imagettfbbox with this script: - the results : - php 4.2.3 with php_gd.dll 99% CPU used and a lot of ram, forced to stop apache service nothing appears in the php error log. - php 4.2.3 with php_gd2.dll "Unable to find font" warning, with a relative link to the font or with an absolute link. no image is drawn. - php 4.3.0RC4 with php_gd.dll 99% CPU used and a lot of ram, forced to stop apache service nothing appears in the php error log. - php 4.3.0RC4 with php_gd2.dll "Could not set character size" warning... Don't know why... And the strange thing is that sometimes the image is drawn, and sometimes not. the script worked before on php 4.2.1, gd2, apache 1.3.?. Previous Comments: [2002-12-26 17:20:50] [EMAIL PROTECTED] Small note, TTF library is not thread safe, meaning that in Win32 enviroment it may not operate well. [2002-12-26 04:55:12] [EMAIL PROTECTED] Hello! I made crash tests using WebRoller software. I set to 10 requests my PHP code from 50 virtual clients simultaneously, and run 40 iterations. I test php with php_gd.dll and php_gd2.dll. in second case apache generates error on windows console (GPF) I use next code: after crash test my system was frosen,apache haves 99% CPU and a lot of memory. As next, I comment string with ImageTTFText function and test it again. Apache lives! Below I will provide output from WebRollers test results: Results from WebRoller with TTF function: --- Start statistics --- --- Basic statistics --- Min:50.00 20.00 30.00 50.00 70.00 60.00 30.00 30.00 Avg:514.82 602.53 785.38 827.82 378.96 238.82 200.40 199.07 Max:3270.00 4990.00 6350.00 7550.00 3410.00 2680.00 510.00 560.00 --- Network traffic details --- Total bytes sent :124242 Total bytes received :347208 Average input speed : 1152 bytes/sec --- Summary times --- Virtual Clients statistics: Count TimeAR/SAT/R 100 1322442 0.0813224.42 110 1290436 0.0911731.24 101 1320349 0.0813072.76 101 1320809 0.0813077.32 114 1260793 0.0911059.59 110 1262395 0.0911476.32 99 1234395 0.0812468.64 101 1293280 0.0812804.75 101 1320759 0.0813076.82 111 1263257 0.0911380.69 Total work time:1337293 Total requests made:1048 Total average time per request: 1198.4126 Total average requests per second: 0.8344 --- Errors report --- Total 425 errors!!! Net :6 T/O :419 --- HTTP response codes details --- CodeCount 200 629 --- End statistics --- Results from WebRoller without TTF function: --- Start statistics --- --- Basic statistics --- Min:60.00 110.00 90.00 100.00 100.00 100.00 50.00 40.00 Avg:188.26 189.40 189.84 189.44 190.40 188.78 187.64 187.96 Max:240.00 280.00 310.00 330.00 290.00 260.00 270.00 280.00 --- Network traffic details --- Total bytes sent :475530 Average output speed : 47553 bytes/sec Total bytes received : 1844000 Average input speed : 2382 bytes/sec --- Summary times --- Virtual Clients statistics: Count TimeAR/SAT/R 400 78002 5.13195.01 400 78052 5.12195.13 400 77862 5.14194.66 400 78162 5.12195.41 400 78262 5.11195.66 400 78202 5.11195.51 400 78122 5.12195.31 400 78202 5.11195.51 400 78232 5.11195.58 400 77942 5.13194.85 Total work time:78342 Total requests made:4000 Total average time per request: 19.5948 Total average requests per second: 51.0341 --- HTTP response codes details --- CodeCount 200 4000 --- End statistics --- -- Edit this bug report at http://bugs.php.net/?id=21189&edit=1
#21216 [NEW]: phpize passes --no-verify to ltconfig without specifying host
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.7-STABLE PHP version: 4.3.0 PHP Bug Type: *Configuration Issues Bug description: phpize passes --no-verify to ltconfig without specifying host The phpize program creates a configure file that executes ltconfig with --no-verify but does not specify the host, FreeBSD ltconfig (libtool 1.3.4) requires the host be specified when the --no-verify parameter is passed, this results in the configure failing. When libtool 1.4 is installed the problem is resolved however 1.3.4 is what is in FreeBSD ports. This has been verified to be true with PHP 4.3.0 release on FreeBSD 4.7-STABLE with at least the curl, mhash and bz2 extensions. My configuration is as follows: AMD Athlon 1 GHZ CPU (686 class) FreeBSD 4.7 256 MB RAM Apache 1.3.27 PHP 4.3.0 Libtool: (GNU libtool) 1.3.4-freebsd-ports My PHP configuration line is: './configure' '--with-apxs=/usr/local/sbin/apxs' '--with-mcrypt' '--with-mhash' '--with-zlib' '--with-bz2' '--with-interbase' '--with-pdflib' '--with-gd' '--with-pgsql' '--with-mysql' '--enable-ftp' The output from the failed configure script is: loading cache /dev/null within ltconfig ltconfig: you must specify a host type if you use `--no-verify' Try `ltconfig --help' for more information. configure: error: libtool configure fail I manually installed libtool 1.4 and the problem went away, however the version of libtool in the FreeBSD ports collection is 1.3.4 so it is what most FreeBSD users will have installed. -- Edit bug report at http://bugs.php.net/?id=21216&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21216&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21216&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21216&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21216&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21216&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21216&r=support Expected behavior: http://bugs.php.net/fix.php?id=21216&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21216&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21216&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21216&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21216&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21216&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21216&r=isapi
#21215 [NEW]: OCI8 calls not taking advantage of SHARED_MODE
From: [EMAIL PROTECTED] Operating system: Linux 2.4 PHP version: 4.2.3 PHP Bug Type: OCI8 related Bug description: OCI8 calls not taking advantage of SHARED_MODE OCIServerAttach() is used, implying that the module should take advantage of shared data mode, but OCIInitilize() was not passed SHARED_MODE flag (#define PHP_OCI_INIT_MODE OCI_DEFAULT), so I don't believe it's really taking advantage of shared data mode. Excerpt from OCI8 docs: To trigger OCI shared mode functionality, process handle parameters must be set and OCIInitialize() must be called with the mode flag set to OCI_SHARED. For example: ub4 mode = OCI_SHARED | OCI_THREADED; OCIInitialize (mode, 0, 0, 0, 0); The first application that initializes OCI in shared mode starts up the shared subsystem using the parameters set by that OCI application. When subsequent applications initialize using the shared mode, they use the previously started shared subsystem. Using this should reduce memory usage when large number of simultaneous connections are open and large numbers of concurrent statements (differing only by bind values) are running. ref: http://www.csee.umbc.edu/help/oracle8/server.815/a67846/basics.htm#425685 -- Edit bug report at http://bugs.php.net/?id=21215&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21215&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21215&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21215&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21215&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21215&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21215&r=support Expected behavior: http://bugs.php.net/fix.php?id=21215&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21215&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21215&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21215&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21215&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21215&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21215&r=isapi
#21214 [Bgs]: ldap_connect returns LDAP link identifier on error.
ID: 21214
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: LDAP related
Operating System: RedHat 8
PHP Version: 4.3.0
New Comment:
See: http://bugs.php.net/bug.php?id=15637
Previous Comments:
[2002-12-27 11:04:51] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
[2002-12-27 10:58:38] [EMAIL PROTECTED]
ldap_connect returns LDAP link identifier on error
The source:
// LDAP variables
$ldaphost = "nonexistendserver"; // your ldap servers
$ldapport = 389; // your ldap server's port number
// Connecting to LDAP
$ldapconn = ldap_connect( $ldaphost, $ldapport )
or die( "Could not connect to {$ldaphost}" );
echo $ldapconn;
returns sth like this:
Resource id #11
Any ideas???
--
Edit this bug report at http://bugs.php.net/?id=21214&edit=1
#21214 [Opn->Bgs]: ldap_connect returns LDAP link identifier on error.
ID: 21214
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: LDAP related
Operating System: RedHat 8
PHP Version: 4.3.0
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
Previous Comments:
[2002-12-27 10:58:38] [EMAIL PROTECTED]
ldap_connect returns LDAP link identifier on error
The source:
// LDAP variables
$ldaphost = "nonexistendserver"; // your ldap servers
$ldapport = 389; // your ldap server's port number
// Connecting to LDAP
$ldapconn = ldap_connect( $ldaphost, $ldapport )
or die( "Could not connect to {$ldaphost}" );
echo $ldapconn;
returns sth like this:
Resource id #11
Any ideas???
--
Edit this bug report at http://bugs.php.net/?id=21214&edit=1
#21214 [NEW]: ldap_connect returns LDAP link identifier on error.
From: [EMAIL PROTECTED]
Operating system: RedHat 8
PHP version: 4.3.0
PHP Bug Type: LDAP related
Bug description: ldap_connect returns LDAP link identifier on error.
ldap_connect returns LDAP link identifier on error
The source:
// LDAP variables
$ldaphost = "nonexistendserver"; // your ldap servers
$ldapport = 389; // your ldap server's port number
// Connecting to LDAP
$ldapconn = ldap_connect( $ldaphost, $ldapport )
or die( "Could not connect to {$ldaphost}" );
echo $ldapconn;
returns sth like this:
Resource id #11
Any ideas???
--
Edit bug report at http://bugs.php.net/?id=21214&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21214&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21214&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21214&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21214&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21214&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21214&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21214&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21214&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21214&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21214&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21214&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21214&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21214&r=isapi
#15209 [Ver]: Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x
ID: 15209
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: Scripting Engine problem
Operating System: RH Linux 7.2
PHP Version: 4.3.0-dev
New Comment:
I created a patch to add this functionality back under mod_php4
systems. This patch was posted to the php-dev list yesterday. Check
out the list archives. An improved patch will be posted later today.
Previous Comments:
[2002-12-23 11:25:38] [EMAIL PROTECTED]
The following script will cause IE to stop loading the page when
zlib.output_compression is used. This was not true before the changes
to register_shutdown_function as the output was not sent.
You can see a test at http://dealnews.com/zlibshutdown.php. Mozilla
gracefully handles the mixed output by truncating the non-compressed
data.
This is in the HTML body.
[2002-12-12 11:37:31] [EMAIL PROTECTED]
I gave up on my patch. Too much work, not enought time, and
ultimately, I couldn't find a place in PHP land where PHP was still
running and Apache had closed the connection to put my hooks in. There
may be a way to tell Apache to close the connection through SAPI, but I
am not aware of it. (I'm not an apache hacker). Someone posted a way
to fork a process to the background, but it isn't a PHP land solution.
>From Carsten Gehling:
Maybe this is what you need?
http://www.naken.cc/mikehup.php
I use this on a CMS site, where the users upload imagefiles with ftp.
After
that, they use a php webinterface to start an importscript (written in
Perl). By doing this command in php:
system("/usr/local/bin/mikehup /usr/bin/perl
/www/servers/netlag/cronscripts/import_billede.pl &");
The importscript is started and executes in the background while the
php-script finishes execution.
Hope that helps
- Carsten
[2002-12-12 10:06:43] [EMAIL PROTECTED]
I copy my mail sent to the dev list here too, to make it more
noticable:
I know there was some hot discussion about this topic but I really need
to
get
this bug fixed. Even I'll make a patch with my zero knowledge of c if
no one
would like to make it, but please try to find a reasonable sollution
that
fits (almost) everyone's need.
I thought of one. I think a new function with the name
register_apache_shutdown_function (or somethink like this) might be
good.
It's name would say that it only works in apache, it could be
documented
that
it's the *only* function that closes the connection before the
registered
functions are handled. Or maybe a parameter could tell if the
connection
should be closed before the first registered function is started.
I'll hope there's some way to solve this problem, because it's not easy
to
tell every customer to use our patch (or use 4.0.6) before they are
staring
to use our programs that rely on this forgotten feature.
Thanks,
Arpi
[2002-12-11 08:30:38] [EMAIL PROTECTED]
Changing to 'Verified', since there is some disagreement on how this
function should operate.
[2002-10-12 10:21:46] [EMAIL PROTECTED]
Marking as critical since this worked at some point.
And there was also posting by [EMAIL PROTECTED] with a possible
fix on [EMAIL PROTECTED]
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/15209
--
Edit this bug report at http://bugs.php.net/?id=15209&edit=1
#21169 [Opn]: Compile Failure, and lots of warnings.
ID: 21169 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: UnixWare 7.1.3 -PHP Version: 4.3.0RC4 +PHP Version: 4.3.0 New Comment: I tried the 4.3.0 release tarball, and similar results. The make.out for it is at: http://www.lerctr.org/~ler/php/make.4.3.0.out.txt It's size is: -rw-r--r--1 ler isis 183136 Dec 27 10:35 make.4.3.0.out.txt My offer stands to give an account to ANY PHP team member to figure out what's going on here. Previous Comments: [2002-12-23 19:35:34] [EMAIL PROTECTED] The make/configure output are here: http://www.lerctr.org/~ler/php/qa-out.txt The size is: $ ls -l qa* -rw-r--r--1 ler isis 211699 Dec 23 19:33 qa-out.txt $ I can supply an account on request for this box. [2002-12-23 19:32:30] [EMAIL PROTECTED] UnixWare 7.1.3, Pentium 4, 1.70GHZ, 768Meg Ram. I can supply a test account. I'll attach the configure output and the compile output. Configure input: $ cat config.ler CC="cc -Xb" CFLAGS="-O" ./configure \ --with-apxs=/usr/internet/apache/bin/apxs \ --enable-safe-mode --enable-calendar --enable-ftp \ --with-gd=/usr/local --with-pgsql=/usr/local/pgsql \ --with-imap=/home/ler/SOURCE/imap/imap-2002a \ --with-imap-ssl=/home/ler/SOURCE/imap/imap-2002a \ --enable-shmop --enable-sysvsem --enable-sysvshm \ --without-mysql --with-jpeg-dir=/usr/local \ --with-ttf-dir=/usr/local --with-openssl=/usr/local/ssl \ --with-zlib --enable-bcmath $ -- Edit this bug report at http://bugs.php.net/?id=21169&edit=1
#19901 [Opn->Csd]: Cannot use ssl functions of java within php
ID: 19901 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Java related Operating System: Linux Redhat 7.1 PHP Version: 4.2.3 New Comment: Problem solved easily... It's a problem with configuration. I removed the following line from php.ini java.home = /usr/java/j2sdk1.4.0_02 Somewhere in php.net, someone says that line should be. Well, I think this line makes java vm to search libraries only under this directory. After deleting it, it used its setup defaults (I guess) and it worked perfectly. Thanx. Previous Comments: [2002-10-14 09:45:12] [EMAIL PROTECTED] Address of php.ini is updated as follows: http://www.denizweb.net/php.ini.txt [2002-10-14 09:38:43] [EMAIL PROTECTED] I have a class which make use of basic ssl functions under java. I am running this class from console and everything works fine. Connection with my bank is established and transaction is completed. I do the same things under php. Create a java object and run the needed functions. Everything runs until the connection phase. Whenever I want to connect to my bank server with ssl, function returns following error: java.net.SocketException: Default SSL context init failed: Algorithm SunX509 not available Running code and error can be seen at http://www.denizweb.net/testjava.php http://www.denizweb.net/testjava.phps phpinfo can be seen at http://www.denizweb.net/phpinfo.php a copy of my ini file can be seen at http://www.denizweb.net/php.ini Apache 1.3.26 statically linked. Note that, these links will remain until someone finds a solution. P.S.: The source code of class is not public and my Bank refuses revealing the source code. But they say that, the class is general and should run perfectly on any tcp/ip and java enabled system. They are also working on the problem and sent me many small classes to find the problem. We are focused on connection part, because php & java integration works without any problems. -- Edit this bug report at http://bugs.php.net/?id=19901&edit=1
#21213 [NEW]: invalid entities handling into set_attribute() and set_content()
From: [EMAIL PROTECTED]
Operating system: All
PHP version: 4.3.0RC4
PHP Bug Type: DOM XML related
Bug description: invalid entities handling into set_attribute() and set_content()
Please take a look at following example:
');
$root = $xml->root();
$value = $root->set_attribute('a','a&b');
$value = $root->set_content('a&b');
echo $xml->dump_mem();
?>
It produces following results:
a&b
As you may see - & entity is treated as literals when it is being set
as attribute value while same entity is treated as entity reference being
set as node value.
I have checked PHP's DOMXML extension source, libxml2 sources and discuss
about this behaviour with Daniel Viellard (libxml2 maintainer) and with
some other people on public XML-related forums and here is some
information about this issue:
1. Such behaviour is not a libxml2 bug, it is expected behaviour. Moreover
it is more correct from a point of specifications.
2. There should be a way to access Attr DOM object as specified into DOM
Level 1 specification
3. There should be a way to control entites handling into passed values.
As a way to go i want to propose you to add one additional argument to
set_attribute(), set_content() and maybe some other functions - $options.
For now there will be 2 options:
XML_KEEP_ENTITIES - to treat all entities as entites and create them as
EntityReference DOM objects
XML_QUOTE_ENTITIES - to treat all entities as literals and hence quote all
special symbols in them (such as '&' char).
For compatibility reasons $options for set_attribute() may be set to
XML_QUOTE_ENTITIES as default value and $options for set_content() - for
XML_KEEP_ENTITIES.
Internally you probably should change xmlSetProp() call into
domxml_elem_set_attribute() to xmlNodeSetContentLen() when there is
$options=XML_KEEP_ENTITIES.
--
Edit bug report at http://bugs.php.net/?id=21213&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21213&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21213&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21213&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21213&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21213&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21213&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21213&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21213&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21213&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21213&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21213&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21213&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21213&r=isapi
#16676 [Bgs->]: ob_implicit_flush not turning off ob
ID: 16676 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Won\'t fix Bug Type: Output Control Operating System: Slackware 8.0 PHP Version: 4.2.0 New Comment: Should have been won't fix Previous Comments: [2002-12-27 08:16:53] [EMAIL PROTECTED] It is easy to make it actually flush output. Difficult part is make it work always. Some output buffers shouldn't be deleted and cannot be deleted. i.e. Some browsers will freeze if server send malformed compressed output. Thus ob_end_flush() wouldn't and shouldn't work in some cases. If it works, it's a bug should be fixed. Fix is simple, but you have to live with that. If you are interested, search php-dev archive. BTW, ob_implicit_flush() simply enable SAPI level auto flushing even if its name imply PHP output buffer flushing. Don't blame me, I'm for fixing it ;) [2002-12-24 21:39:37] [EMAIL PROTECTED] You can solve your problem by putting @ob_end_flush(); on top of your command line scripts. [2002-12-24 16:25:58] [EMAIL PROTECTED] iliaa, I appreciate you trying to point me to help, but I still think I'm right about this bug report. I've tried it on several machines with each stable version of PHP since the report. Now still with 4.2.3 I'm seeing the same thing. Again, I'm not using zlib output compression cause I let mod_gzip do that in apache. This is for a php shell script. As you said, flush would send the output, but according to the documentation, ob_implicit_flush() should "result in a flush operation after every output call, so that explicit calls to flush() will no longer be needed". I'm saying ob_implicit_flush is broken in 4.2.x and does not call flush() after each echo, or if it does, it's still not outputting to STDOUT. By default, php.ini has 4k of output buffering. I want to leave that for the rest of the applications I'm running and since you can't modify the ini value with ini_set(), I'm resorting to the ob_* functions. Instead of calling ob_end_flush() at the start of the script cause according to the docs on that, as part of its functionality, it turns off ob. Either way, I'm getting output buffering turned off while leaving 4k buffering in php.ini, but I doesn't mean that ob_implicit_flush() might still be not working right. I guess I'll just wait a few more days for 4.3.0 and try that out. [2002-09-26 16:47:23] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. if you are not using ob and do not have gzip compression enabled, then by simply doing flush(); you'll get the data your are outputing sent to screen without any output buffering. [2002-04-18 11:34:07] [EMAIL PROTECTED] > If you need to flush, do not use output buffers at all. That's what I'm trying to do, use ob_implicit_flush() at the beginning of my script to turn off ob. > Imagine turning on/off compression, converting one encoding to another, etc in the middle of transmission. It just does not work. I'm not wanting to change encoding or turn zlib compression on/off the middle of a script. I just have a basic 400 line script I'd like to output. I simply don't want to have ob turned on. 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/16676 -- Edit this bug report at http://bugs.php.net/?id=16676&edit=1
#21212 [NEW]: strtotime fails when crossing year
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 4.2.3
PHP Bug Type: Date/time related
Bug description: strtotime fails when crossing year
/* function strftime produce wrong result with a timestamp close to the end
of
Year,the four digit year value is sometimes 1 year after (see
"30/12/2002")
and sometimes 1 year before (see "01/01/2005") the good one.
hope this help
*/
$dateTab=array();
$dateTab[0] = "Dec 29 2001";
$dateTab[1] = "Dec 30 2001";
$dateTab[2] = "Dec 31 2001"; wrong output with strftime
$dateTab[3] = "Jan 01 2002";
$dateTab[4] = "Dec 29 2002";
$dateTab[5] = "Dec 30 2002"; wrong output with strftime
$dateTab[6] = "Dec 31 2002"; wrong output with strftime
$dateTab[7] = "Jan 01 2003";
$dateTab[8] = "Dec 28 2003";
$dateTab[9] = "Dec 29 2003"; wrong output with strftime
$dateTab[10] = "Dec 30 2003"; wrong output with strftime
$dateTab[11] = "Dec 31 2003"; wrong output with strftime
$dateTab[12] = "Jan 01 2004";
$dateTab[13] = "Dec 28 2004";
$dateTab[14] = "Dec 29 2004";
$dateTab[15] = "Dec 30 2004";
$dateTab[16] = "Dec 31 2004";
$dateTab[17] = "Jan 01 2005"; wrong output with strftime
$dateTab[18] = "Jan 02 2005"; wrong output with strftime
$dateTab[19] = "Jan 03 2005";
$dateTab[20] = "Jan 04 2005";
$dateTab[21] = "Jan 05 2005";
foreach($dateTab as $currentDate) {
if (($timestamp = strtotime($currentDate)) === -1)
{
echo "The string ($currentDate) is bogus";
}
else
{
$result[0] = date('d/m/Y',$timestamp);
$result[1] = strftime("%d/%m/%G",$timestamp);
if($result[1] == $result[0]) {
echo "$currentDate == $result[0] == $result[1]";
}
else
{
echo "$currentDate == $result[0] != $result[1]";
}
}
}
--
Edit bug report at http://bugs.php.net/?id=21212&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21212&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21212&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21212&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21212&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21212&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21212&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21212&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21212&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21212&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21212&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21212&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21212&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21212&r=isapi
#16676 [Opn->Bgs]: ob_implicit_flush not turning off ob
ID: 16676 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Output Control Operating System: Slackware 8.0 PHP Version: 4.2.0 Previous Comments: [2002-12-27 08:16:53] [EMAIL PROTECTED] It is easy to make it actually flush output. Difficult part is make it work always. Some output buffers shouldn't be deleted and cannot be deleted. i.e. Some browsers will freeze if server send malformed compressed output. Thus ob_end_flush() wouldn't and shouldn't work in some cases. If it works, it's a bug should be fixed. Fix is simple, but you have to live with that. If you are interested, search php-dev archive. BTW, ob_implicit_flush() simply enable SAPI level auto flushing even if its name imply PHP output buffer flushing. Don't blame me, I'm for fixing it ;) [2002-12-24 21:39:37] [EMAIL PROTECTED] You can solve your problem by putting @ob_end_flush(); on top of your command line scripts. [2002-12-24 16:25:58] [EMAIL PROTECTED] iliaa, I appreciate you trying to point me to help, but I still think I'm right about this bug report. I've tried it on several machines with each stable version of PHP since the report. Now still with 4.2.3 I'm seeing the same thing. Again, I'm not using zlib output compression cause I let mod_gzip do that in apache. This is for a php shell script. As you said, flush would send the output, but according to the documentation, ob_implicit_flush() should "result in a flush operation after every output call, so that explicit calls to flush() will no longer be needed". I'm saying ob_implicit_flush is broken in 4.2.x and does not call flush() after each echo, or if it does, it's still not outputting to STDOUT. By default, php.ini has 4k of output buffering. I want to leave that for the rest of the applications I'm running and since you can't modify the ini value with ini_set(), I'm resorting to the ob_* functions. Instead of calling ob_end_flush() at the start of the script cause according to the docs on that, as part of its functionality, it turns off ob. Either way, I'm getting output buffering turned off while leaving 4k buffering in php.ini, but I doesn't mean that ob_implicit_flush() might still be not working right. I guess I'll just wait a few more days for 4.3.0 and try that out. [2002-09-26 16:47:23] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. if you are not using ob and do not have gzip compression enabled, then by simply doing flush(); you'll get the data your are outputing sent to screen without any output buffering. [2002-04-18 11:34:07] [EMAIL PROTECTED] > If you need to flush, do not use output buffers at all. That's what I'm trying to do, use ob_implicit_flush() at the beginning of my script to turn off ob. > Imagine turning on/off compression, converting one encoding to another, etc in the middle of transmission. It just does not work. I'm not wanting to change encoding or turn zlib compression on/off the middle of a script. I just have a basic 400 line script I'd like to output. I simply don't want to have ob turned on. 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/16676 -- Edit this bug report at http://bugs.php.net/?id=16676&edit=1
#16676 [Bgs->Opn]: ob_implicit_flush not turning off ob
ID: 16676 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Output Control Operating System: Slackware 8.0 PHP Version: 4.2.0 New Comment: It is easy to make it actually flush output. Difficult part is make it work always. Some output buffers shouldn't be deleted and cannot be deleted. i.e. Some browsers will freeze if server send malformed compressed output. Thus ob_end_flush() wouldn't and shouldn't work in some cases. If it works, it's a bug should be fixed. Fix is simple, but you have to live with that. If you are interested, search php-dev archive. BTW, ob_implicit_flush() simply enable SAPI level auto flushing even if its name imply PHP output buffer flushing. Don't blame me, I'm for fixing it ;) Previous Comments: [2002-12-24 21:39:37] [EMAIL PROTECTED] You can solve your problem by putting @ob_end_flush(); on top of your command line scripts. [2002-12-24 16:25:58] [EMAIL PROTECTED] iliaa, I appreciate you trying to point me to help, but I still think I'm right about this bug report. I've tried it on several machines with each stable version of PHP since the report. Now still with 4.2.3 I'm seeing the same thing. Again, I'm not using zlib output compression cause I let mod_gzip do that in apache. This is for a php shell script. As you said, flush would send the output, but according to the documentation, ob_implicit_flush() should "result in a flush operation after every output call, so that explicit calls to flush() will no longer be needed". I'm saying ob_implicit_flush is broken in 4.2.x and does not call flush() after each echo, or if it does, it's still not outputting to STDOUT. By default, php.ini has 4k of output buffering. I want to leave that for the rest of the applications I'm running and since you can't modify the ini value with ini_set(), I'm resorting to the ob_* functions. Instead of calling ob_end_flush() at the start of the script cause according to the docs on that, as part of its functionality, it turns off ob. Either way, I'm getting output buffering turned off while leaving 4k buffering in php.ini, but I doesn't mean that ob_implicit_flush() might still be not working right. I guess I'll just wait a few more days for 4.3.0 and try that out. [2002-09-26 16:47:23] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. if you are not using ob and do not have gzip compression enabled, then by simply doing flush(); you'll get the data your are outputing sent to screen without any output buffering. [2002-04-18 11:34:07] [EMAIL PROTECTED] > If you need to flush, do not use output buffers at all. That's what I'm trying to do, use ob_implicit_flush() at the beginning of my script to turn off ob. > Imagine turning on/off compression, converting one encoding to another, etc in the middle of transmission. It just does not work. I'm not wanting to change encoding or turn zlib compression on/off the middle of a script. I just have a basic 400 line script I'd like to output. I simply don't want to have ob turned on. [2002-04-18 06:12:03] [EMAIL PROTECTED] Don't worray, it's known issue. I can make it flush when all output buffers registered may be flushed, otherwise it just does not work. Imagine turning on/off compression, converting one encoding to another, etc in the middle of transmission. It just does not work. If you need to flush, do not use output buffers at all. Note: Older PHP is just deleted the last output buffer registered with ob_implicit_flush. This is wrong behavior. 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/16676 -- Edit this bug report at http://bugs.php.net/?id=16676&edit=1
#9852 [Com]: Header redirect and db connection cause "CGI misbehaved"
ID: 9852 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.2.1 New Comment: Good Afternoon, I have seen many comments regarding PHP should be compliant with enterprise software. I would suggest that it is - UNIX and Apache are enterprise level solutions and PHP is a ROCK star on those platforms. Just because we are no forcing it to do things on an AXX Backward platform like MS W2k and XP is not a reason to complain. I have run into the issue, because I am having to rewrite our authentication scripts because the IIS CGI cannont handle a simple authentication redirect. Before you blame PHP, try looking at all the garbage hoops that IIS puts you through. Nicolas Previous Comments: [2002-11-14 06:36:33] [EMAIL PROTECTED] Just for your information: Don't blame PHP. ASP.net ALSO SHOWS LOTS OF "CGI ERROR". I solve this problem by slowing down connection -- do not put src='xxx.php/asp' in your frame tag. use onload() handler to load page into frames with javascript AFTER the frame page is loaded. [2002-10-29 14:00:20] [EMAIL PROTECTED] I'm happy to hear that most people are able to solve their CGI errors by changing the Windows Performance Options. We have Scott to thank for this little trick! Rasmus, I think what people are upset about is that this bug was closed. It's obviously a Micro$haft problem (big surprise) but even so, it's quite frustrating to feel like y'all don't give a dern :-( This is obviously not the case but closing the bug makes people think that you're not interested in finding a solution. Even if the problem is not the fault of PHP. On an unrelated note I'm *extremely happy* to see that you've included the php_zip.dll extension in php-4.3.0pre2-Win32.zip. SWT! Now all we need is a solid php4isapi.dll ;-) Ottawa [2002-10-28 19:35:21] [EMAIL PROTECTED] We fix what we can fix given our resources and the environment we are working in. In many ways M$ does not provide us with a level playing-field and as such you will find that PHP is much much stronger on non-M$ platforms where we are not hampered by closed-source, vague and often quite buggy apis. But thank you for your amazingly constructive comments. [2002-10-28 18:59:46] [EMAIL PROTECTED] I was having major problems with this just as everyone else was so I changed my setting from being optimized for background processes to applications and everything seems to be working smoothly. That said, I am very disappointed with PHP, and I really hope that the developers learn from their mistakes... especially this one. This type of error cannot be tolerated, especially when it's been present for this long. Version after version... nobody seems to be paying attention to it. I'm sorry, but I think I will be moving to asp.net if php cannot handle the speed of our servers. I understand that bringing up asp.net in a PHP forum is not a good idea, however I'm just stating the facts. Farewell PHP, I might be back, but in the mean time I choose not to put my reputation into the hands of ignorant programmers. [2002-10-28 08:41:44] [EMAIL PROTECTED] On our servers, we were recieving this cgi error a lot. I haven't installed the specific patch or updated MDAC. (web server - w2k sp3 iis 5, fast; mssql server - w2k sp3 mssql 2000, fast; all on a 1gb private net). My web server was set to background by default. I changed to APPLICATION and things have been working well. It seems that folks are using the background setting after the updates and patches. Don't know if this is of any use, but I thought I'd let people know. Also, I only recieve the CGI error on the IE browser. I have yet to recieve it on Mozilla. Thanks Seth 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/9852 -- Edit this bug report at http://bugs.php.net/?id=9852&edit=1
#21200 [Csd]: --with-mssql doesn't work
ID: 21200 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: MSSQL related Operating System: linux (Linux sdesktop 2.4.18-4GB PHP Version: 4.2.3 New Comment: Thank you. Previous Comments: [2002-12-26 12:35:07] [EMAIL PROTECTED] --with-mssql is only available from PHP 4.3.0. You can use a cvs snapshot or RC4. [2002-12-26 10:41:19] [EMAIL PROTECTED] I tried to ./configure PHP with "./configure --with-apxs --with-mysql --with-mssql" but it doesn't pick up the latter. I also tried "--with-mssql=/home/user/freetds-0.60" or "--with-mssql=/home/user/freetds-0.60/src". It just doesn't recognize the "--with-mssql" part. I removed the comment from php.ini (which is placed in /usr/local/lib and found by phpinfo()) anyways, but no luck. The manual backs up my "--with-mssql" theory. But no luck. Whatever options I put to "./configure" it works. Strangly that it doesn't list "--with-mssql" when I do a "./configure --help" Thanks, Till -- Edit this bug report at http://bugs.php.net/?id=21200&edit=1
