Bug #11578 Updated: http header order not respected and messages not transmitted
ID: 11578
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: HTTP related
Operating System: win32 (nt4 and 2000)
PHP Version: 4.0.5
New Comment:
[EMAIL PROTECTED]
thanks for your interest in my bugsuite... but i'm sorry to tell you
that the project was closed (due to no feedback..) and i've currently
no samples of my code running.. and i'm in difficult to find the latest
sources, i'll look for them and i'll send you via comments later,
(maybe today)
thank for your interest.
xavier.
Previous Comments:
[2002-02-06 01:02:54] [EMAIL PROTECTED]
[EMAIL PROTECTED] - Do you have a web site where this sample script
you pasted here is running? It would help me analyze this if I could
view the headers myself.
I have a very strong suspicion about what is going on. The Location
header is not simply another header, but rather it also alters the
server response code to be a 300 level response rather than a 200 OK. I
believe that the Location header might either be:
1) the only header in the response that is sent, so all of your
authentication headers are not sent, or
2) the only header that the HTTP client (browser) bothers to interpret
since the response code is a 301 Moved Permanently.
Your feedback would be greatly appreciated. Thanks for helping!
[2001-06-22 01:13:09] [EMAIL PROTECTED]
yes i've tried this second undocumented argument and like i've
explained it this solve the first part of my problem. but i think that
i not explain my problem correctly.
I call some getallheader successivly after have sended my arguments but
: it doesn't return that i see on the network and if after have written
the content of getallheader if i do a redirection my code doesn't work
(maybe the optimizer change the order of the execution ).
Thanks
[2001-06-21 17:58:53] [EMAIL PROTECTED]
Did you try with the 2nd (undocumented before) argument
for header() like Rasmus suggested??
And it still doesn't work?
[2001-06-21 09:59:22] [EMAIL PROTECTED]
thanks a lot ramus for your help.. the first part of the problem was my
fault not the php fault.. but... the second part is always not
functionnal...
i can obtain the correct headers and response for the ntlm scheme but..
if i do a header("location : "); at the END of the program... the
value are not written correctly !!
maybe an optimizer miss optimization.
It strange that on a test without redirection all seems correct but
adding instruction after the write and the file was closed and flushed
this is not functionnal...
thank a lot and sorry to spam you with my little problem. but it's a
mission critical projet for France Telecom Mobile service (ORANGE) and
i prefer using php with linux than IIS... i need to prove the
possibilities of the open source platform..
Thank.
[2001-06-21 09:21:45] [EMAIL PROTECTED]
By default PHP's header() function will replace the value
of an http header with the value you give it. If you don't
want it to replace, but instead add a second header with
a different value, use the optional second arg to header()
to tell PHP not to do this replace. So your code should be:
header("www-authenticate: Negociate");
header("www-authenticate: NTLM",0);
I don't blame you for not knowing this though. It isn't
documented anywhere. I will take care of that now.
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/11578
--
Edit this bug report at http://bugs.php.net/?id=11578&edit=1
Bug #15684: Undefined symbol "pthread_getspecific"
From: [EMAIL PROTECTED] Operating system: FREEBSD 4.4-STABLE PHP version: 4.1.1 PHP Bug Type: *Compile Issues Bug description: Undefined symbol "pthread_getspecific" Configured php4.1.1 (latest from snaps.php.net as of last night) with options --with-mysql --with-apxs2=/path/to/my/apxs . Configured, built and installed , but when running apachectl configtest / restart , I get this error. bash-2.05# apachectl configtest Syntax error on line 215 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp4.so into server: /usr/local/apache2/modules/libphp4.so: Undefined symbol "pthread_getspecific" However, I have rebuilt this after installing gnu portable threads from ports, and using the configure line as follows bash-2.05# ./configure --with-tsrm-pth --with-mysql --with-apxs2=/usr/local/apache2/bin/apxs this builds and installs afterwards. Is this a bug in freeBSD threads , or a bug in php ? Thanks :) -- Edit bug report at http://bugs.php.net/?id=15684&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15684&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15684&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15684&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15684&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15684&r=support Expected behavior: http://bugs.php.net/fix.php?id=15684&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15684&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15684&r=submittedtwice
Bug #15684 Updated: Undefined symbol "pthread_getspecific"
ID: 15684 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Compile Issues Operating System: FREEBSD 4.4-STABLE PHP Version: 4.1.1 New Comment: sorry, just checked the version of php, and it's actually PHP/4.2.0 from snaps.php.net :P Previous Comments: [2002-02-23 04:53:26] [EMAIL PROTECTED] Configured php4.1.1 (latest from snaps.php.net as of last night) with options --with-mysql --with-apxs2=/path/to/my/apxs . Configured, built and installed , but when running apachectl configtest / restart , I get this error. bash-2.05# apachectl configtest Syntax error on line 215 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp4.so into server: /usr/local/apache2/modules/libphp4.so: Undefined symbol "pthread_getspecific" However, I have rebuilt this after installing gnu portable threads from ports, and using the configure line as follows bash-2.05# ./configure --with-tsrm-pth --with-mysql --with-apxs2=/usr/local/apache2/bin/apxs this builds and installs afterwards. Is this a bug in freeBSD threads , or a bug in php ? Thanks :) -- Edit this bug report at http://bugs.php.net/?id=15684&edit=1
Bug #14594 Updated: Failed to compile/run when using Apache 2.x, unresolved symbols
ID: 14594 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: FreeBSD 4.4-STABLE PHP Version: 4.1.0 New Comment: I just found this bug after I posted #15684 . If you want a workaround, install gnu-pth , and configure with --with-tsrm-pth as part of your options. Previous Comments: [2002-01-09 05:57:34] [EMAIL PROTECTED] Exactly the same dump with 4.1.1 with apache 2.0.28 on exactly the same os. [2001-12-18 18:40:35] [EMAIL PROTECTED] I compiled standard Apache-2.0.28beta, then downloaded php-4.1.0, compiled it just with --with-mysql and --with-apxs2=/usr/local/apache2/bin/apxs After sucessful make install, I tried to run /usr/local/apache2/bin/httpd, which resulted in this error: Syntax error on line 3 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp4.so into server: /usr/local/apache2/modules/libphp4.so: Undefined symbol "pthread_getspecific" -- Edit this bug report at http://bugs.php.net/?id=14594&edit=1
Bug #15685: Fail on apache make/ php_mysql.c:undef.ref.
From: [EMAIL PROTECTED] Operating system: SuSE Linux 6.3 PHP version: 4.1.1 PHP Bug Type: Compile Failure Bug description: Fail on apache make/ php_mysql.c:undef.ref. Hi, I hope that someone can help- my problem is exactly the one in bug report #5030, which has been closed with "should work now", but no hint HOW the guy got it to work. My system: SuSe Linux 6.3 Apache 1.3.23 MySQL 3.23.47 PHP 4.1.1 The Guy from #5030 had different versions, but got the same fail on the apache make: I configure and build php4 with: ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/sbin/apxs --enable-track-vars --with-xml --with-gettext --with-xml --with-mycrypt and then configure and build apache-1.3.23 with: ./configure --prefix=/usr/local/apache --activate-module=src/modules/php4/libphp4.a This thing works fine, until when I run make, which terminates with: ... modules/php4/libphp4.a(php_mysql.o): In function `php_mysql_field_info': /home/admin/php-4.0.0/ext/mysql/php_mysql.c:1574: undefined reference to `mysql_field_seek' /home/admin/php-4.0.0/ext/mysql/php_mysql.c:1575: undefined reference to `mysql_fetch_field' collect2: ld returned 1 exit status make[2]: *** [target_static] Error 1 make[2]: Leaving directory `/home/admin/apache_1.3.12/src' make[1]: *** [build-std] Error 2 make[1]: Leaving directory `/home/admin/apache_1.3.12' make: *** [build] Error 2 What am I doing wrong ? Is there some option that I could include with my apache- configure ? Thanks, Robert Zrim -- Edit bug report at http://bugs.php.net/?id=15685&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15685&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15685&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15685&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15685&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15685&r=support Expected behavior: http://bugs.php.net/fix.php?id=15685&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15685&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15685&r=submittedtwice
Bug #15686: xml2-config not used
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.1 PHP Bug Type: *Compile Issues Bug description: xml2-config not used at ./configure, xml2-config is not used to get xml2 libs. Instead, just "-lxml2 -L/path/to/xml2dir" is used. This means that if xml2 is configured with pthread support, nothing after the xml2 section of ./configure will compile. For me, this showed up when detecting jpeg support. Instead of using "-lxml2 -L/path/to/xml2dir", obviously `xml2-config --libs` should be used. -- Edit bug report at http://bugs.php.net/?id=15686&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15686&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15686&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15686&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15686&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15686&r=support Expected behavior: http://bugs.php.net/fix.php?id=15686&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15686&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15686&r=submittedtwice
Bug #14423 Updated: PHP won't compile with --with-iconv turned on
ID: 14423 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: FreeBSD 4.4-STABLE PHP Version: 4.1.0 New Comment: I'm experiencing the same Problem with PHP4.1.1 and FreeBSD 4.5 Previous Comments: [2002-01-24 09:06:32] [EMAIL PROTECTED] Yes, just tried on 4.5-PRERELEASE. [2002-01-23 16:29:09] [EMAIL PROTECTED] Does it *always* fail with the former configure line? [2001-12-24 10:48:32] [EMAIL PROTECTED] Here is configure, which works fine. But I cannot find out what caused it to fail in previous case... './configure' '--with-config-file-path=/usr/local/etc/php.standalone' '--disable-pear' '--enable-discard-path' '--with-readline=/usr' '--enable-versioning' '--with-system-regex' '--disable-debug' '--enable-track-vars' '--with-gd=/usr/local' '--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-zlib' '--with-mysql=/usr/local' '--with-pgsql=/usr/local' '--with-openssl=/usr' '--with-xml' '--with-xmlrpc=/usr/local' '--with-ttf' '--with-freetype' '--enable-xslt' '--with-xslt-sablot' '--with-expat-dir=/usr/local' '--with-dom=/usr/local' '--enable-ftp' '--with-iconv=/usr/local' '--enable-bcmath' '--enable-sockets' '--prefix=/usr/local' 'i386--freebsd4.5' [2001-12-11 07:35:41] [EMAIL PROTECTED] System: [never@mile ~]$ uname -a FreeBSD mile.nevermind.kiev.ua 4.4-STABLE FreeBSD 4.4-STABLE #0: Tue Dec 4 21:12:20 EET 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/mile i386 [never@mile ~]$ pkg_info | grep iconv-2 iconv-2.0_1 Charset conversion library and utilities How to repeat: ./configure '--with-mysql=/usr/local' '--with-pgsql=/usr/local' '--enable-track-vars' '--enable-sockets' '--enable-ftp' '--with-ttf' '--with-gd=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-freetype-dir=/usr/local' '--with-freetype' '--with-zlib-dir=/usr/local' '--with-iconv=/usr/local' '--enable-xslt' '--enable-wddx' '--with-xslt-sablot' '--with-expat-dir=/usr/local' make Output: Making all in . /bin/sh /usr/local/src/php-4.1.0/libtool --silent --mode=link gcc -I. -I/usr/local/src/php-4.1.0/ -I/usr/local/src/php-4.1.0/main -I/usr/local/src/php-4.1.0 -I/usr/local/src/php-4.1.0/Zend -I/usr/local/include/freetype2/freetype -I/usr/local/include/gd -I/usr/local/include -I/usr/local/include/mysql -I/usr/local/src/php-4.1.0/TSRM -g -O2 -o php -export-dynamic stub.lo libphp4.la ./.libs/libphp4.a(internal_functions.o): In function `php_startup_internal_extensions': /usr/local/src/php-4.1.0/main/internal_functions.c(.data+0x28): undefined reference to `iconv_module_entry' *** Error code 1 Stop in /usr/local/src/php-4.1.0. *** Error code 1 Stop in /usr/local/src/php-4.1.0. -- Edit this bug report at http://bugs.php.net/?id=14423&edit=1
Bug #15651 Updated: Output is broken
ID: 15651
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: *General Issues
Operating System: Win2K-Server / UNIX
PHP Version: 4.1.1
New Comment:
I made test using the advised method, and found that crush appears in
one my simple function "call". A simple example goes below:
Note: actually cutting line goes some earlier than that crush point,
but, I think it's because some PHP bufferization, and is not important
now.
Previous Comments:
[2002-02-22 06:35:16] [EMAIL PROTECTED]
Could you set up linux/freebsd box to reproduce this bug?
And generate backtrace. (Or get exit code with gdb)
You can write "error_log(__FILE__.'(.'__LINE__.')')"
to locate to find ofending function/line also.
[2002-02-21 21:27:48] [EMAIL PROTECTED]
Sorry. I wanted to say "... My site is complex enough..."
[2002-02-21 21:25:45] [EMAIL PROTECTED]
I tryed to make some small scripts before, but there were no problems
with them. My site is complete enough, there is a lot of includes (but
execution time for homepage on my PC is less than 1 sec.). It looks
like there are no problems for simply scripts, but I'll try again to
make something ...
By that time, if you like you may watch the results on different
servers:
1) php4.0.6: http://www.sec4.wfdns.com/www.freetakeout.com/
2) php4.1.1: http://vh110014.radntech.ca/fto/
- you may try to click some links there ("log-in to your account", for
example) to see the difference in cutting point.
[2002-02-21 20:26:05] [EMAIL PROTECTED]
If you can create _short_ & _complete_ script that reproduces the
problem. We can fix it :)
[2002-02-21 18:37:26] [EMAIL PROTECTED]
Unfortunately, my home OS is Win2K-Server, and I myself don't have VC++
to try to build PHP from sources...
Can I provide any useful information for you, using my OS software
which I already have?
I have both IIS and Apache web servers.
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/15651
--
Edit this bug report at http://bugs.php.net/?id=15651&edit=1
Bug #15651 Updated: Output is broken
ID: 15651
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *General Issues
Operating System: Win2K-Server / UNIX
PHP Version: 4.1.1
New Comment:
I've found a decision of problem: I simply need replase line
if (is_array($argv[0])) $argv=&$argv[0];
to:
if (is_array($argv[0])) $argv=$argv[0];
And I'll not lose any fuctionality features.
So, crush appears when an array element assigns to the same array by
reference. Althow this operation is not very often and very useful :-),
it works correctly and w/o crush in 4.0.6 version, and I think this
crush should be fixed though.
Previous Comments:
[2002-02-23 06:46:36] [EMAIL PROTECTED]
I made test using the advised method, and found that crush appears in
one my simple function "call". A simple example goes below:
Note: actually cutting line goes some earlier than that crush point,
but, I think it's because some PHP bufferization, and is not important
now.
[2002-02-22 06:35:16] [EMAIL PROTECTED]
Could you set up linux/freebsd box to reproduce this bug?
And generate backtrace. (Or get exit code with gdb)
You can write "error_log(__FILE__.'(.'__LINE__.')')"
to locate to find ofending function/line also.
[2002-02-21 21:27:48] [EMAIL PROTECTED]
Sorry. I wanted to say "... My site is complex enough..."
[2002-02-21 21:25:45] [EMAIL PROTECTED]
I tryed to make some small scripts before, but there were no problems
with them. My site is complete enough, there is a lot of includes (but
execution time for homepage on my PC is less than 1 sec.). It looks
like there are no problems for simply scripts, but I'll try again to
make something ...
By that time, if you like you may watch the results on different
servers:
1) php4.0.6: http://www.sec4.wfdns.com/www.freetakeout.com/
2) php4.1.1: http://vh110014.radntech.ca/fto/
- you may try to click some links there ("log-in to your account", for
example) to see the difference in cutting point.
[2002-02-21 20:26:05] [EMAIL PROTECTED]
If you can create _short_ & _complete_ script that reproduces the
problem. We can fix it :)
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/15651
--
Edit this bug report at http://bugs.php.net/?id=15651&edit=1
Bug #15687: include_path at installation misses '.'
From: [EMAIL PROTECTED]
Operating system: windows
PHP version: 4.1.1
PHP Bug Type: PHP options/info functions
Bug description: include_path at installation misses '.'
hi,
i'm trying to support people newly installing the postnuke system (lots of
PHP files including each other), and since about the middle january i see
several people that just installed some PHP package with an include path
that is empty or contains '..' in stead of '.' .
This way the relative include('file.php') fails, of course.
Unfortunately these people are so 'newbie' that they cannot even reply
where they got PHP from. Either here, in a package or in a linux
distribution?? Sorry a about that, i realise it does not help much.
One of them had windows... the others didn't tell...
Chris
--
Edit bug report at http://bugs.php.net/?id=15687&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15687&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15687&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15687&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15687&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15687&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15687&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15687&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15687&r=submittedtwice
Bug #15688: undefined symbol:stat
From: [EMAIL PROTECTED] Operating system: SuSe Linux 7.3 PHP version: 4.1.1 PHP Bug Type: Informix related Bug description: undefined symbol:stat i can configure PHP4 with Informix as dynamic module without getting errors. But when i try to start th Apache server i get the error message Cannot load /usr/lib/apache/libphp4.so into server: opt/informix/lib/esql/libifgen.so: undefined symbol /usr/sbin/apachectl start: httpd could not be started configure: ./configure --with-config-file-path=/etc --with-apxs --with-informix Linux version: Suse 7.3 Informix cdsk version: 9.51UC1 Make: version 3.79.1 gcc version: 2.95.3 flexversion: 2.5.4 bison version: 1.28 httpd version: 1.3.20 I trying since several days to get it running, i have serched a lot of sites for a solutiion, and tried out several changes in generating and setting Variables but it's always the same. Can the problem solved by PHP or is it a problem of the Informix cdsk? Thanks for any help. Winfried -- Edit bug report at http://bugs.php.net/?id=15688&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15688&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15688&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15688&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15688&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15688&r=support Expected behavior: http://bugs.php.net/fix.php?id=15688&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15688&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15688&r=submittedtwice
Bug #15687 Updated: include_path at installation misses '.'
ID: 15687
Updated by: [EMAIL PROTECTED]
-Summary: include_path at installation misses '.'
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: PHP options/info functions
Operating System: windows
PHP Version: 4.1.1
New Comment:
Anyway, this is no bug with PHP.
The default is to NOT set the include path in any INI file, which then
defaults to
".:/lib/php" on Unix systems
and
"c:\\php4\\pear" on windows systems
Please not that the latter does not require the current path because,
well yeah, that's the way it works under windows as we all know.
Just a personal advice: without talking to your users and getting on
track where they got their PHP from you have to be a wizard to solve
it.
If you're application only depends on 'itself', it may be an option for
you to manually set the include_path (if not forbidden by
configuration).
Previous Comments:
[2002-02-23 09:17:12] [EMAIL PROTECTED]
hi,
i'm trying to support people newly installing the postnuke system (lots
of PHP files including each other), and since about the middle january
i see several people that just installed some PHP package with an
include path that is empty or contains '..' in stead of '.' .
This way the relative include('file.php') fails, of course.
Unfortunately these people are so 'newbie' that they cannot even reply
where they got PHP from. Either here, in a package or in a linux
distribution?? Sorry a about that, i realise it does not help much.
One of them had windows... the others didn't tell...
Chris
--
Edit this bug report at http://bugs.php.net/?id=15687&edit=1
Bug #15685 Updated: Fail on apache make/ php_mysql.c:undef.ref.
ID: 15685 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: SuSE Linux 6.3 PHP Version: 4.1.1 New Comment: You're messing with static and dynamic builds of PHP. You should either compile Apache normally (without PHP, but with --enable-module=so), and PHP with --with-apxs=/path/to/apxs, or compile PHP with --with-apache=/path/to/apache and Apache with --activate-module=/path/to/php/module For more information see the manual or ask support on the appropriate mailinglist. Previous Comments: [2002-02-23 05:25:32] [EMAIL PROTECTED] Hi, I hope that someone can help- my problem is exactly the one in bug report #5030, which has been closed with "should work now", but no hint HOW the guy got it to work. My system: SuSe Linux 6.3 Apache 1.3.23 MySQL 3.23.47 PHP 4.1.1 The Guy from #5030 had different versions, but got the same fail on the apache make: I configure and build php4 with: ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/sbin/apxs --enable-track-vars --with-xml --with-gettext --with-xml --with-mycrypt and then configure and build apache-1.3.23 with: ./configure --prefix=/usr/local/apache --activate-module=src/modules/php4/libphp4.a This thing works fine, until when I run make, which terminates with: ... modules/php4/libphp4.a(php_mysql.o): In function `php_mysql_field_info': /home/admin/php-4.0.0/ext/mysql/php_mysql.c:1574: undefined reference to `mysql_field_seek' /home/admin/php-4.0.0/ext/mysql/php_mysql.c:1575: undefined reference to `mysql_fetch_field' collect2: ld returned 1 exit status make[2]: *** [target_static] Error 1 make[2]: Leaving directory `/home/admin/apache_1.3.12/src' make[1]: *** [build-std] Error 2 make[1]: Leaving directory `/home/admin/apache_1.3.12' make: *** [build] Error 2 What am I doing wrong ? Is there some option that I could include with my apache- configure ? Thanks, Robert Zrim -- Edit this bug report at http://bugs.php.net/?id=15685&edit=1
Bug #15689: more variable type should be added
From: [EMAIL PROTECTED] Operating system: PHP version: 4.1.1 PHP Bug Type: Feature/Change Request Bug description: more variable type should be added php class has no `operator` behave like c++ so, it's quite different between user-defined-object and internal-variable-type i suggest that wide-string type should be added. which behave like wchar_t in vc, but more powerful wide-string is not that mbstring mbstring is an extension not internal type every char of wide-string is wide-char(wchar), both ascii and multibyte-char there's also a bunch of wide-string operating function in i18n mbstring is so complexity that use more cpu-time wide-string take more memory but simple to process samples: $str = "string"; // This is a normal string $wstr = L"string"; // This is a wide-string echo strlen($str); // 6 echo strlen($wstr); // also 6 echo memsize($wstr); // 6 echo memsize($wstr); // 12 echo $str == $wstr; // true echo $str === $wstr; // false "\x20"; // normal string L"\x20"; // wide-string L"\x4c3a"; // wide-string and echo preg_replace(L"/abc/", "def", "abcdef"); should also works for matching wide-string if (strpos(L"abc", L"def") === false) .; see? quite different from "mbstring" but.. if adding wchar_t support to every string function make it slower, i'd like to have a set of "w" prefix functions such as wstrcmp wstrpos wpreg_replace not "mb" :p if php preferer mbstring rather than wchar_t at least, make mbstring internal, not as extension. when compiled without mbstring, all mbstring-type is processed exactly like normal string. that's all -- Edit bug report at http://bugs.php.net/?id=15689&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15689&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15689&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15689&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15689&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15689&r=support Expected behavior: http://bugs.php.net/fix.php?id=15689&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15689&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15689&r=submittedtwice
Bug #12475 Updated: the variable $PHP_SELF is not set.
ID: 12475 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Variables related Operating System: Windows 2000 Server PHP Version: 4.0.6 New Comment: Hi. I also have this Problem, even with the newest version of PHP (4.1.1, using the *.msi file). I'm using Xitami, but I can't be that, because when using PHP3, all works well. Is there a fix? Previous Comments: [2002-01-14 02:07:49] [EMAIL PROTECTED] No feedback, closing. [2001-12-24 10:06:34] [EMAIL PROTECTED] Can you try 4.1.0 or even 4.1.1 (when it's out) or the latest CVS (snaps.php.net)? [2001-09-15 17:35:02] [EMAIL PROTECTED] Was able to verify this. Anyone able to provide any information about why this occurs? [2001-07-30 21:12:49] [EMAIL PROTECTED] if I open a script containing only the phpinfo() function, the $PHP_SELF field is not filled in. In my own scripts it's not setted at all. I'm using the zipped version of php4.06 with cgi wrapper using xitami 2.4d6 running as a windows service. -- Edit this bug report at http://bugs.php.net/?id=12475&edit=1
Bug #15690: $PHP_SELF empty
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.1.1 PHP Bug Type: Scripting Engine problem Bug description: $PHP_SELF empty Using PHP 4.1.1. (I downloaded the *.msi package) and Xitami 2.4d9 on Windows 2000. $PHP_SELF seems not to be set. phpinfo() gives me an empty field, in scripts it is not set at all. When I use PHP3 everything is okay. Who can I fix this? Does it work with the ZIP-file (but it's 4 MB, phew, I'm a modem user)? Anybody got a solution? -- Edit bug report at http://bugs.php.net/?id=15690&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15690&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15690&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15690&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15690&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15690&r=support Expected behavior: http://bugs.php.net/fix.php?id=15690&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15690&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15690&r=submittedtwice
Bug #15661 Updated: Corporate Name Change
ID: 15661 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type:Documentation problem PHP Version: 4.1.1 Assigned To: imajes New Comment: Thanks again for all your hard work. Velocis is now called Birdstep RDM Server http://www.birdstep.com/database_technology/rdm_server.php3 THanks again. Jennifer Previous Comments: [2002-02-21 14:07:26] [EMAIL PROTECTED] You don´t need to inform the translators. The change was made in global.ent and all translated manuals would use the link in global.ent. There is only ONE global.ent in the phpdoc repository [2002-02-21 13:49:47] [EMAIL PROTECTED] i have also only updated the url to the Birdstep/Velocis product, currently. other locations for this can be found here: http://www.php.net/~imajes/velocis.txt and http://www.php.net/~imajes/velocis-doc.txt [2002-02-21 13:47:36] [EMAIL PROTECTED] Jennifer, we have a module right now called "velocis", which I assume to be the module that deals with your product. I wonder if you have a new (one word) name you'd like to call it, and then we can update the code appropriately. There are a number of references to velocis all over the source, both for the php4 code and documentation. [2002-02-21 13:45:32] [EMAIL PROTECTED] Depends. Official mirrors will update the English version shortly. Translators of the various languages will translate it when they feel like it--after which the changes will propagate out to the mirrors again. :) Anybody else who is hosting the manual is responsible for keeping their copy up to date with the official one, so you'd email them, not us. But no, no new bug reports are needed to php.net. We'll do what we can, but we don't control all copies of the manual. Cheers, Torben [2002-02-21 13:31:01] [EMAIL PROTECTED] Thanks for all your hard work. Just one question...am I to assume that all sites with this manual on it in different languages, etc. will also be updated? Or do I need to email a separate bug report for each time I come across it??? Jennifer 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/15661 -- Edit this bug report at http://bugs.php.net/?id=15661&edit=1
Bug #15691: Returns from strpos()
From: [EMAIL PROTECTED] Operating system: Any PHP version: 4.1.1 PHP Bug Type: Feature/Change Request Bug description: Returns from strpos() It would be boundlessly helpful if someone could make strpos(), etc. return a -1 instead of FALSE like C++/Java. Returning a FALSE (something that casts to an integer of 0) doesn't seem to make much sense. Even if it can be worked around with strpos() === FALSE, it would be a lot easier without having to rely upon it. Any reason why it should be using FALSE instead of -1? -- Edit bug report at http://bugs.php.net/?id=15691&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15691&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15691&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15691&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15691&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15691&r=support Expected behavior: http://bugs.php.net/fix.php?id=15691&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15691&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15691&r=submittedtwice
Bug #15691 Updated: Returns from strpos()
ID: 15691 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Any PHP Version: 4.1.1 New Comment: Changing this behavior will break way too many scripts, so it's absolutely not a good idea to change this behavior. Derick Previous Comments: [2002-02-23 15:12:51] [EMAIL PROTECTED] It would be boundlessly helpful if someone could make strpos(), etc. return a -1 instead of FALSE like C++/Java. Returning a FALSE (something that casts to an integer of 0) doesn't seem to make much sense. Even if it can be worked around with strpos() === FALSE, it would be a lot easier without having to rely upon it. Any reason why it should be using FALSE instead of -1? -- Edit this bug report at http://bugs.php.net/?id=15691&edit=1
Bug #15551 Updated: unset($_SESSION['var']) problem with register_globals=on
ID: 15551
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Session related
Operating System: Win32
PHP Version: 4.1.1
New Comment:
[EMAIL PROTECTED] wrote:
> If you cannot control the setting of register_globals,
> you should use the session_register() functions
while earlier he wrote:
> If you are using $HTTP_SESSION_VARS/$_SESSION, do not use
> session_register(), session_is_registered() and
> session_unregister() unless you know internal of session
> module.
> In other words, don't use register_globals(on) and
> $_SESSION together.
So then, how exactly am I supposed to make sessions work if I can't
access the session arrays? $GLOBALS? $_GLOBALS?
$*GLOBALS != sessions.
I must admit that I'm sorely disappointed in the way PHP development
has been proceding as of 4.0.6 Sessions are horribly broken, the
documentation is just plain wrong, there's very little developer
support, and the default answer to every session problem seems to be
'don't use session_* with any of the session arrays. Don't use any of
the session arrays if the ini file has been modified from the defaults.
Learn the internals of the session module."
Which leavs PHP, for all intents and purposes, without session
support.
Might I suggest the developers and documentation maintainers advise
against the use of sessions until such time as they work? With 'work'
defined as backward-compatible with prior versions of PHP AND (this is
important) functional with respect to what the documentation says.
I really don't feel like should have to grok the internals of the
session module just to be able to use sessions. This is why the
session module is a module (module being defined as a black box
componant).
HAND
Previous Comments:
[2002-02-14 12:17:29] [EMAIL PROTECTED]
Funny guy, as you could see in my demonstration script, I'm capable of
unregistering variables from session having register_globals enabled. I
just don't like the way how that has to be done.
By and by I get tired of writing new workarounds for new bugs (from
which almost all were session related). My session handling class
meanwhile contains three workarounds, which are applied depending on
the php version and its configuration. If session handling would work
as expected, I wouldn't have to use my (workaround-bloated)class
anymore.
Furthermore it makes no sense to me, to introduce a new clean way of
handling session variables, while making it impossible to be used by
developers that have to consider backwards compatibility. (By the way,
I belive this silly behaviour could be fixed ...)
[2002-02-14 09:11:21] [EMAIL PROTECTED]
If you cannot control the setting of register_globals, you should use
the session_register() functions _or_ learn the internals of the
session module :)
Regards, Marc.
[2002-02-14 08:28:51] [EMAIL PROTECTED]
And how I'm supposed to write good, compatible code while I can't tell
my customers what they have to configure on their server, because my
application is not supposed to be the only one running there?
If the references would point to $_SESSION[*] and be stored in
$GLOBALS[*] instead of pointing to $_GLOBALS[*] and being stored in
$_SESSION[*], you could use $_SESSION[*] regardless of
register_globals.
[2002-02-14 07:16:42] [EMAIL PROTECTED]
extract from the session documentation:
If register_globals is enabled, [...] users must register variables
with session_register() function.
If you are using $HTTP_SESSION_VARS/$_SESSION, do not use
session_register(), session_is_registered() and session_unregister()
unless you know internal of session module.
In other words, don't use register_globals(on) and $_SESSION together.
Regards, Marc.
[2002-02-14 06:22:07] [EMAIL PROTECTED]
Hi F0lks,
when I use the $_SESSION array while register_globals is enabled, I
can't unregister variables as described in the documentation (
unset($_SESSION['var']); ), except in the script call where 'var' was
used first time.
I wrote demonstration script hoping it shows you what I mean.
(register_globals must be enabled!)
';
if( ! $_SESSION['c'] ) $_SESSION['c'] = 1;
echo "=== unregistering variables from session with register_globals=On
under PHP 4.1.1 ===\n";
echo "Current step: $_SESSION[c] of 5\n\n";
switch( $_SESSION['c'] ) {
case 1:
echo "Checking, if 'var' is registered - ";
if( session_is_registered('var') ) {
session_destroy();
Bug #15692: ISAPI fputs \n = \r\n
From: [EMAIL PROTECTED] Operating system: Any Windows platform PHP version: 4.1.1 PHP Bug Type: Filesystem function related Bug description: ISAPI fputs \n = \r\n The PHP.EXE CGI treats this code snippet: ... fwrite($file, "\r\n"); ... exactly as expected. However the ISAPI.DLL version converts "\n" to "\r\n" so the real output in the file is: "\r\r\n" Is there a place in the source code where I can make the ISAPI filter to be compiled without the conversion? I think it's a bug anyway. Thank you Cheers Jakub -- Edit bug report at http://bugs.php.net/?id=15692&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15692&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15692&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15692&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15692&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15692&r=support Expected behavior: http://bugs.php.net/fix.php?id=15692&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15692&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15692&r=submittedtwice
Bug #15693: HTTP HEAD request executes entire script
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.5 PHP version: 4.1.1 PHP Bug Type: HTTP related Bug description: HTTP HEAD request executes entire script Maybe this is the way it's supposed to work, but it doesn't make a whole lot of sense to me. When processing a HEAD request, mod_php executes the script as if it were a normal GET request. This is unexpected (at least to me) and can lead to unexpected results, such as duplicate execution when dealing with browsers that use a HEAD request prior to a GET request. For example, test script test.php: and assuming test.out exists and is world-writable. HEAD /test.php HTTP/1.0 causes the file test.out to be appended to. This is not what I would expect, but maybe it's unavoidable. A workaround is to look at $_SERVER['REQUEST_METHOD'] and do nothing if it's a HEAD request. './configure' '--with-apxs=/usr/local/sbin/apxs' '--with-config-file-path=/usr/local/etc' '--enable-versioning' '--with-system-regex' '--disable-debug' '--enable-track-vars' '--without-gd' '--without-mysql' '--with-zlib' '--with-mcrypt=/usr/local' '--with-mysql=/usr/local' '--prefix=/usr/local' 'i386--freebsd4.5' -- Edit bug report at http://bugs.php.net/?id=15693&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15693&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15693&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15693&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15693&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15693&r=support Expected behavior: http://bugs.php.net/fix.php?id=15693&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15693&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15693&r=submittedtwice
Bug #15694: array_filter does not work withing classes
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.1.1 PHP Bug Type: Arrays related Bug description: array_filter does not work withing classes There is no way to safely use array filter from within a class. Using class::functionname should work for the callback function as in: but this just says: Warning: array_filter() expects argument 2, 'test::filter', to be a valid callback in /usr/home/ribrdb/web/php/classtest.php on line 11 -- Edit bug report at http://bugs.php.net/?id=15694&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15694&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15694&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15694&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15694&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15694&r=support Expected behavior: http://bugs.php.net/fix.php?id=15694&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15694&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15694&r=submittedtwice
Bug #15694 Updated: array_filter does not work withing classes
ID: 15694 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: linux PHP Version: 4.1.1 New Comment: >From the manual (http://www.php.net/array_filter): Note: Instead of a function name, an array containing an object reference and a method name can also be supplied. So the correct code would be: Torben Previous Comments: [2002-02-23 19:56:56] [EMAIL PROTECTED] There is no way to safely use array filter from within a class. Using class::functionname should work for the callback function as in: but this just says: Warning: array_filter() expects argument 2, 'test::filter', to be a valid callback in /usr/home/ribrdb/web/php/classtest.php on line 11 -- Edit this bug report at http://bugs.php.net/?id=15694&edit=1
Bug #15695: Documentation http title string
From: [EMAIL PROTECTED] Operating system: KDE/Linux PHP version: 4.1.1 PHP Bug Type: Documentation problem Bug description: Documentation http title string This is not really a bug, it's just an easily implementable suggestion which would make the PHP-online documentation a bit better: Currently, the title which appears in the webbrowser's titlebar is something like this: "PHP: Manual: function" In a crowded toolbar, this will be truncated, so you don't know what function is displayed in the window. I suggest that this is changed to: "function - PHP - Manual" (or something similar like "function: PHP: Manual") This way, you see the function name in the operating system's toolbar, even if it's truncated. Thank you P.S.: The PHP online-documentation is the best online-documentation I've ever seen for a language and it's this documentation which lets me prefer PHP over Perl. -- Edit bug report at http://bugs.php.net/?id=15695&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15695&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15695&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15695&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15695&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15695&r=support Expected behavior: http://bugs.php.net/fix.php?id=15695&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15695&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15695&r=submittedtwice
Bug #15695 Updated: Documentation http title string is truncated in toolbar
ID: 15695 Updated by: [EMAIL PROTECTED] -Summary: Documentation http title string Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem -Operating System: KDE/Linux +Operating System: KDE/Linux (affects all) PHP Version: 4.1.1 New Comment: This is not really a bug, it's just an easily implementable suggestion which would improve the PHP-online documentation: Currently, the title which appears in the webbrowser's titlebar is something like this: "PHP: Manual: function" In a crowded toolbar, this will be truncated, so you don't know what function is displayed in the window. I suggest that this is changed to: "function - PHP - Manual" (or something similar like "function: PHP: Manual") This way, you see the function name in the operating system's toolbar, even if it's truncated. Thank you P.S.: The PHP online-documentation is the best online-documentation I've ever seen for a language and it's this documentation which lets me prefer PHP over Perl. Previous Comments: [2002-02-23 21:40:27] [EMAIL PROTECTED] This is not really a bug, it's just an easily implementable suggestion which would make the PHP-online documentation a bit better: Currently, the title which appears in the webbrowser's titlebar is something like this: "PHP: Manual: function" In a crowded toolbar, this will be truncated, so you don't know what function is displayed in the window. I suggest that this is changed to: "function - PHP - Manual" (or something similar like "function: PHP: Manual") This way, you see the function name in the operating system's toolbar, even if it's truncated. Thank you P.S.: The PHP online-documentation is the best online-documentation I've ever seen for a language and it's this documentation which lets me prefer PHP over Perl. -- Edit this bug report at http://bugs.php.net/?id=15695&edit=1
Bug #15506 Updated: _SESSION not being created
ID: 15506 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: Session related Operating System: Linux RH7 PHP Version: 4.1.1 Previous Comments: [2002-02-11 10:45:13] [EMAIL PROTECTED] The auto global _SESSION is not being created with session.auto_start on for my Linux Apache/PHP installation. It works however when running on my Win98 laptop using Apache and the PHP 4.1.1 binary from php.net. I ran this script on both platforms: '; print_r(array_keys($GLOBALS)); print ''; ?> Win32 output: Array ( [0] => HTTP_POST_VARS [1] => _POST [2] => HTTP_GET_VARS [3] => _GET [4] => HTTP_COOKIE_VARS [5] => _COOKIE [6] => HTTP_SERVER_VARS [7] => _SERVER [8] => HTTP_ENV_VARS [9] => _ENV [10] => HTTP_POST_FILES [11] => _FILES [12] => _REQUEST [13] => HTTP_SESSION_VARS [14] => _SESSION [15] => GLOBALS ) Linux output: Array ( [0] => HTTP_POST_VARS [1] => _POST [2] => HTTP_GET_VARS [3] => _GET [4] => HTTP_COOKIE_VARS [5] => _COOKIE [6] => HTTP_SERVER_VARS [7] => _SERVER [8] => HTTP_ENV_VARS [9] => _ENV [10] => HTTP_POST_FILES [11] => _FILES [12] => _REQUEST [13] => GLOBALS ) I've verified that the php.ini files are identical (minus path differences). I have register_globals Off and transparent SID enabled. PHP 4.1.1 configuration: ./configure --enable-trans-sid --with-apxs=/usr/local/apache/bin/apxs --with-imap --with-imap-ssl=/usr/local/ssl --with-openssl=/usr/local/ssl --with-kerberos=/usr/kerberos Apache 1.3.23 with mod_ssl PHP application in /usr/local/apache/zeus with appropriate VirtualHost and Directory directives in Apache httpd.conf /usr/local/apache/zeus contains this .htaccess file php_flag register_globals off php_flag short_open_tag off php_flag asp_tags off # allow_call_time_pass_reference has been deprecated but xml_set_object requires it php_flag allow_call_time_pass_reference on php_flag session.use_trans_sid on php_value session.save_handler files php_value session.save_path /usr/local/apache/zeus/sessions php_flag session.auto_start on php_flag session.use_cookies off php_value session.name ZEUSSID php_value session.cookie_lifetime 0 php_value session.cookie_path / php_value session.cache_limiter nocache php_value session.serialize_handler php php_value include_path /usr/local/apache/zeus/php/xAPP;/usr/local/apache/zeus/php Forcetype application/x-httpd-php I have AllowOverride set to All in the Apache conf file to allow all this to work. I have verified the permissions on the sessions directory. The owner of the directory is the Apache user. The sessions are being created but no data is being saved in them--$_SESSION is not available. My scripts are built on auto-start and using $_SESSION to keep things as simple as possible. I've tried removing the .htaccess file, using the default session config (from the distribution) and using explicit session_start() at the top of the page and still $_SESSION is not created (works on Win32 though). Added a bogus value to $_SESSION after session_start() does not work either--still 0 byte session files. Only creates a normal PHP hash called $_SESSION. It appears that the session module is not registering $_SESSION or $HTTP_SESSION_VARS as globals. Thanks, Vic Ivers -- Edit this bug report at http://bugs.php.net/?id=15506&edit=1
Bug #15573 Updated: save_handler mm - doesn't create _SESSION[bar] at the first-time
ID: 15573 Updated by: [EMAIL PROTECTED] -Summary: save_handler mm - doesn't create _SESSION[bar] at the first-time Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: Session related Operating System: debian woody (3.0) PHP Version: 4.1.1 Previous Comments: [2002-02-15 11:43:44] [EMAIL PROTECTED] Hi, if I use mm as save handler. I have to click twice at the first time to increment the counter. With files it works fine. cheers, Marcus. click me"; ?> -- Edit this bug report at http://bugs.php.net/?id=15573&edit=1
Bug #15428 Updated: Session does not allow to update variables
ID: 15428
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
Bug Type: Session related
Operating System: FreeBSD
PHP Version: 4.1.1
Previous Comments:
[2002-02-08 04:43:08] [EMAIL PROTECTED]
function check_session()
{
global $SEID, $lang, $vars;
session_start($SEID);
if( !(session_is_registered('lang')) )
{
$lang='D';
session_register('lang');
}
}
check_session();
global $basket;
if (!session_is_registered('basket') || $basket==null || $basket=="")
{
$basket=array();
session_register('basket');
}
/* this funstion is used to store in a session data about every
article, the call is always the same, but after a first call it saves
data, on a second call it adds data to an array but does not update
data in a session, on PHP 4.0.4 and 4.0.6 it works perfect under
freeBSD and Linux */
function add()
{
global $art_name, $size, $qty, $model_number, $color, $customer_id,
$maxqty, $ek_price, $vk_price, $program, $vars, $magras, $la_type,
$program_n, $color_n, $season, $size_names, $lafirm, $collection_name;
global $basket, $max_qtys;
//walking in a busket for checking an existance of the same artikel
$i=0;
$exists=false;
while(isset($basket[$i]))
{
$tmp=$basket[$i];
$ki=0;
while($ki<7)
{
$tmpn="lab".$ki;
global $$tmpn;
if (check_digit($$tmpn) && $$tmpn!=0)
{
if($tmp['ID'] == $model_number && $tmp['size'] ==
$size_names[$magras][$ki] && $tmp['color'] == $color)
{
$basket[$i]['qty']+= $$tmpn;
$exists = true;
break;
}
}
$ki++;
}
$i++;
}
if ($exists != true)
{
$ki=0;
while($ki<7)
{
$tmpn="lab".$ki;
global $$tmpn;
if(check_digit($$tmpn) && $$tmpn != 0)
{
$qty_real=min($max_qtys[($size_names[$magras][$ki])], $$tmpn);
$tmp=array(
"ID" => $model_number,
"name" => $art_name,
"size" => $size_names[$magras][$ki],
"qty" => $qty_real,
"maxqty" => $max_qtys[($size_names[$magras][$ki])],
"color" => $color,
"program" => $program,
"customer" => $customer_id,
"ek_price" => "$ek_price",
"vk_price" => "$vk_price",
"magras" => $magras,
"la"=>($ki+1),
"program_n"=> $program_n,
"color_n"=> $color_n,
"agent" => $vars['username'],
"season"=> $season,
"collection"=>$lafirm,
"collection_name"=>$collection_name
);
array_push($basket, $tmp);//echo $tmp['ID']." ".$basket[1]['ID'];
}
$ki++;
}
}
}
ini params:
[Session]
; Handler used to store/retrieve data.
session.save_handler = files
; Argument passed to save_handler. In the case of files, this is the
path
; where data files are stored. Note: Windows users have to change this
; variable in order to use PHP's session functions.
session.save_path = /tmp
; Whether to use cookies.
session.use_cookies = 0
; Name of the session (used as cookie name).
session.name = SEID
; Initialize session on request startup.
session.auto_start = 0
; Lifetime in seconds of cookie or, if 0, until browser is restarted.
session.cookie_lifetime = 0
; The path for which the cookie is valid.
session.cookie_path = /
; The domain for which the cookie is valid.
session.cookie_domain =
; Handler used to serialize data. php is the standard serializer of
PHP.
session.serialize_handler = php
; Percentual probability that the 'garbage collection' process is
started
; on every session initialization.
session.gc_probability = 3
; After this number of seconds, stored data will be seen as 'garbage'
and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440
; Check HTTP Referer to invalidate externally stored URLs containing
ids.
session.referer_check =
; How many bytes to read from the file.
;session.entropy_length = 0
; Specified here to create the session id.
;session.entropy_file =
;session.entropy_length = 16
;session.entropy_file = /dev/urandom
; Set to {nocache,private,public} to determine HTTP caching aspects.
session.cache_limiter = nocache
; Document expires after n minutes.
session.cache_expire = 180
; use transient sid support if enabled by compiling with
--enable-trans-sid.
session.use_trans_sid = 1
url_rewriter.tags =
"a=href,area=href,frame=src,input=src,form=fakeentry"
[2002-02-07 21:14:02] [EMAIL PROTECTED]
Short complete script and session realated ini settings are needed
Bug #15447 Updated: Seemingly without some reason, the data of the session disappear.
ID: 15447 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: Session related Operating System: WINDOWS 98 SE PHP Version: 4.1.1 Previous Comments: [2002-02-08 06:32:47] [EMAIL PROTECTED] Hello. I would like to ask him to go open this bug. Seemingly without some reason, the data of the session disappear. I go ties the directory where the session files are stored and they don't simply exist more. I was already accompanying the moments from the creation of the file ties the hour that the same disappears. The times the process doesn't last more than 1 minute and other more than 10 min. I am using php 4. 1. 1, Apache 1. 3. 20, win98 SE 4. 1. (with all of the available updatings in the windowsupdate.microsoft.com). My lan works in speed of 10/100 Mbit. The file php. ini is one copies of the php. ini-dist, only with alterations in the path of the creation of the session files. The remaining continues original. The path is that d:/php/sessiondata. If possible I would like his help for the solution of this problem. Sorry for my terrible english. -- Edit this bug report at http://bugs.php.net/?id=15447&edit=1
Bug #14826 Updated: 4.1.0 on powerpc doesn't save session variables
ID: 14826
Updated by: [EMAIL PROTECTED]
-Summary: 4.1.0 on powerpc doesn't save session variables
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
Bug Type: Session related
Operating System: Debian Linux 2.2.19 ppc
PHP Version: 4.1.0
Previous Comments:
[2002-01-14 13:37:57] [EMAIL PROTECTED]
sure! only logs page under normal acces.log nothing on error log, then
gdb also doesn't shows just nothing! but here's the strace of the
session for same script menthioned on begining: the real thing is that
it says:
(Inappropriate ioctl for device)
what to check?
bests.
open("/var/www/auth3/index34.phtml", O_RDONLY|O_LARGEFILE) = 6
getcwd("/var/www/auth3", 4095) = 15
lstat("/var", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("/var/www/auth3", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("/var/www/auth3/index34.phtml", {st_mode=S_IFREG|0644,
st_size=684, ...}) = 0
ioctl(6, 0x402c7413, 0x7fffe268)= -1 ENOTTY (Inappropriate
ioctl for device)
fstat(6, {st_mode=S_IFREG|0644, st_size=684, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x30016000
read(6, "
[2002-01-11 18:50:24] [EMAIL PROTECTED]
Just making sure again. You don't get any errors (segfualt, etc) in
your apache error log, right?
I just want you to run httpd under gdb to see if you get any signal :)
gdb /usr/sbin/httpd
% run -X
[2002-01-11 06:52:15] [EMAIL PROTECTED]
I'm sorry but my apache doesn't segfault on any moment it serves both
static pages and php pages nicely except for those php apps with
session variables that isn't able to save them.
could be the common unsigned char problem ?
what to check?
[2002-01-10 22:34:22] [EMAIL PROTECTED]
Your httpd may be segfaulting. Run httpd under gdb see if you get
segfault or any.
[2002-01-10 11:18:02] [EMAIL PROTECTED]
umm dosen't seems this here...
teixi@satellite:~$ cat /etc/php4/apache/php.ini | grep -i save.path
session.save_path = /tmp
teixi@satellite:~$ ls -lad /tmp
drwxrwxrwt6 root root 1024 Jan 10 15:52 /tmp
teixi@satellite:~$ uname -a
Linux satellite 2.2.19 #1 Sat Apr 14 23:20:24 CDT 2001 ppc unknown
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/14826
--
Edit this bug report at http://bugs.php.net/?id=14826&edit=1
Bug #15678 Updated: isset fails for 4.1.1 and CVS version
ID: 15678 Updated by: [EMAIL PROTECTED] -Summary: isset failed in the latest cvs tree Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: Variables related Operating System: i686-pc-linux-gnu -PHP Version: 4.0CVS-2002-02-22 +PHP Version: 4.0CVS-2002-02-2 New Comment: It should be fixed before 4.2.0 at least. Hopefully before 4.1.2 :) Previous Comments: [2002-02-22 11:41:57] [EMAIL PROTECTED] Btw, this has nothing to do with current CVS. This applies to at least 4.1.0 I tested (so there's nothing broken since current stable and CVS; if it's broken, it is for a long time) [2002-02-22 11:17:03] [EMAIL PROTECTED] Andrey Hristov wrote: >The answer to your question: > var_dump((int) 'y'); >?> ??? this is not the answer of the second question and also not to the first one, because results: "Notice: Undefined offset: 0 in foo.php on line 2" [2002-02-22 11:03:55] [EMAIL PROTECTED] hi, the declaration of a second dimension in a normal array results a strange array content. results: Array ( [c] => boo ) is this a normal behavior? i think this ist completely wrong, because 'd' is not string position 1. Also a normal condition like results true ... but it is absolutely not true i have test it on linux with the lastest cvs tree php version. regards, Steve -- Edit this bug report at http://bugs.php.net/?id=15678&edit=1
Bug #10807 Updated: error with php
ID: 10807 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: ODBC related Operating System: win95 PHP Version: 3.0.17 New Comment: No feedback was provided for this bug for over a month, 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: [2001-05-11 05:17:43] [EMAIL PROTECTED] please try php 4.0.5 and see if the problem still exists. [2001-05-11 05:14:35] [EMAIL PROTECTED] Hello, I have problem with odbc32.dll et make a fault in php3. Whant can i do? Thank you for the response. Brigitte [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=10807&edit=1
