DO NOT REPLY [Bug 10061] New: - php 4.2.1 apache 2.0.39 cookie problems after sapi make problems

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10061>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10061

php 4.2.1 apache 2.0.39 cookie problems after sapi make problems

           Summary: php 4.2.1 apache 2.0.39 cookie problems after sapi make
                    problems
           Product: Apache httpd-2.0
           Version: 2.0.39
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: Other Modules
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: 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!

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

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org