Bug #16626 Updated: Only last cookie set
| From: | red at tripany dot com | Date: | Thu, 20 Jun 2002 14:03:18 +0000 |
| Subject: | Bug #16626 Updated: Only last cookie set | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-11565@lists.php.net to get a copy of this message | ||
ID: 16626
Updated by: red@tripany.com
Reported By: svein.olav@bjerkeset.com
Status: Duplicate
Bug Type: Apache2 related
Operating System: All
PHP Version: 4.2.1
New Comment:
Well after extensive testing, I have to conclude it's probably not a
php (alone) problem.
I have tried:
PHP ver. Apache ver. --enable-so works? error
---------------------------------------------------------
4.2.1 2.0.39 yes no yes
2.1 36 yes yes no
2.0 39 yes no yes
2.0 36 no no yes
2.0 36 yes yes no
4.0.3pl1 1.3.9 ? yes ?
(4.0.3pl1 is the standard debian package)
The rest of the 2.1 installations (with apache 39) don't work and give
errors, so there's some problem with the apxs interaction between php
and httpd 2.0.39. As php2.1.0 works with httpd 2.0.36 I'm now assuming
there was a change in the apxs of apache in the security fix version
which renders the multiple cookies unwriteable. I'll send this off to
apache as well.
Cheers
Robin
Previous Comments:
------------------------------------------------------------------------
[2002-06-20 07:52:41] red@tripany.com
PS I get the same make error when installing php4.2.0 and removing line
93 from php_functions.c (it's the boundary function again) finishes the
install. Under 4.2.0, I get the same behaviour, so maybe it is apache?
------------------------------------------------------------------------
[2002-06-20 07:41:07] derick@php.net
Dup of #17663, please update only that bugreport!
Derick
------------------------------------------------------------------------
[2002-06-20 07:27:00] red@tripany.com
Hi,
I've installed Apache 2.0.39 on Debian 2.2 and 2.4, which went fine.
Then installing php 4.2.1, the configure goes fine,
./configure --prefix=/opt/php-4.2.1 --enable-force-cgi-redirect
--enable-ftp --enable-magic-quotes --enable-bcmath --enable-calendar
--enable-dbase --enable-dbx --enable-ftp --enable-gd-native-ttf
--enable-mbstring --enable-track-vars --enable-ucd-snmp-hack
--enable-sockets --enable-sysvsem --enable-sysvshm --enable-yp
--enable-shared=PKGS --enable-debug --enable-memory-limit --with-zlib
--with-gd --with-jpeg-dir=/usr/lib --with-tiff-dir=/usr/lib
--with-png-dir=/usr/lib --with-mysql --with-snmp
--with-apxs2=/opt/httpd-2.0.39/bin/apxs
It finds apache2 support, and suggests using apache2filter (which I
think it should be doing)
but the make gives an error:
gcc -I. -I/usr/local/src/php/php-4.2.1/sapi/apache2filter
-I/usr/local/src/php/php-4.2.1/main -I/usr/local/src/php/php-4.2.1
-I/opt/httpd-2.0.39/include -I/usr/local/src/php/php-4.2.1/Zend
-I/usr/local/include -I/usr/local/src/php/php-4.2.1/ext/mysql/libmysql
-I/usr/include/ucd-snmp -I/usr/local/src/php/php-4.2.1/ext/xml/expat
-D_REENTRANT -I/usr/local/src/php/php-4.2.1/TSRM -DTHREAD=1 -g -O2
-pthread -Wall -DZTS -c php_functions.c -fPIC -DPIC -o
php_functions.lo
php_functions.c:93: parse error
make[3]: *** [php_functions.lo] Error 1
make[3]: Leaving directory
`/usr/local/src/php/php-4.2.1/sapi/apache2filter'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/usr/local/src/php/php-4.2.1/sapi/apache2filter'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/php/php-4.2.1/sapi'
make: *** [all-recursive] Error 1
Now if I delete lines 92, 93 and 94 from
sapi/apache2filter/php_functions.c which are:
#if !MODULE_MAGIC_AT_LEAST(20020506,0)
ADD_STRING(boundary);
#endif
and then continue the make, it all seems to go fine. Make install
copies everything to the right directory and doing a <? phpinfo() ?>
shows that everything should be functioning neatly.
Now the problem!
When writing cookies to a client, sometimes the cookie will not be
written and sometimes it will be - this behaviour is consistent in
terms of site a will never write the cookies, but site b will always
write the cookie! (see code below)
Never works
setcookie("netuser", $row["werknemer_ID"], time()+3600, "/");
setcookie["netlanguage", $row["row_lang"], time()+3600,"/");
setcookie["netlastlogin", $row["last_login"], time()+3600,"/");
$werknemer_ID=$HTTP_COOKIE_VARS["netuser"];
Always works
setcookie("user", $userID, time()+(3600*3), "/")
$userID=$HTTP_COOKIE_VARS["soluser"];
The only thing we've managed to figure out is that in the first
example, we write to the cookie 3 times (using similar statements) and
in the second example we only create the cookie once. Every time we
write to the cookie again, it overwrites (deletes) the old cookies and
replaces it with the last cookie. So what you end up with, is the
netlastlogin cookie, and netuser and netlanguage don't exist on the
client harddrive. This used to work under php4.2.0!
Under apache 2.0.36 and php 4.2.0 compiled with the same settings, I
never experienced this behaviour and I have no idea what's causing it!
Any help is much appreciated!
------------------------------------------------------------------------
[2002-05-17 03:12:48] jwoolley@php.net
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version 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.
Thank you for the report, and for helping us make PHP better.
Patch committed. Thanks, regina!
------------------------------------------------------------------------
[2002-05-12 15:17:09] redeye@cs-aktuell.de
Just ran into this problem as i was running apache 2 under win2k with
php 4.2.0 installed as apache module. No Cookie seemed to be set
correctly. I solved this problem by running PHP as CGI binary.
------------------------------------------------------------------------
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/16626
--
Edit this bug report at http://bugs.php.net/?id=16626&edit=1