Re: [PHP] Varying session behavior between 2 nearly identical Apache/PHP setups
Just to be sure...
You've double-checked that page setup code isn't somehow triggering an
ini_set('session.use_trans_id') or other session parameters, right?
I'd also examine any kind of code that is supposed to do something
"different" for the dev/production environment.
Inevitably, there ends up being *SOME* kind of #ifdef in there that
does some configuration thing in dev server to connect to different db
or whatever...
On Tue, December 12, 2006 3:17 pm, Matthew North wrote:
> Hello All,
>
> I have an odd situation that I wonder if someone might have some
> insight on. The scenario is this:
>
> - Two FreeBSD systems running Apache+mod_php+others. We use one for
> development and the other for testing.
>
> - Each system is running PHP 5.2.0 with identical php.ini files.
>
> - On each system we have identical PHP code (confirmed to be identical
> by comparing cksum output) that looks essentially like this:
>
> === snip ===
> .
> . [page setup code]
> .
> trigger_error('['.session_id().']');
> if (needSession && !session_id())
> session_start();
> trigger_error('['.session_id().']');
> .
> . [page output code]
> .
> ?>
> === snip ===
>
> Errors are logged to file rather than the page, so the trigger_error()
> calls above result in entries similar to:
>
> [08-Dec-2006 16:59:23] PHP Notice: [] in /path/to/file.php on line
> 178
>
> [08-Dec-2006 16:59:23] PHP Notice: [GmQidWwShpRpHCGDiQrBr-Lk4ib] in
> /path/to/file.php on line 181
>
> So it appears a session is started.
>
> However, on the test system a session cookie is never sent back to the
> browser so the session cannot be restored, while on the development
> system everything works as it should (session cookie is set and
> session is therefore restored on each page load).
>
> Using 'wget -S', here are the response headers sent by the development
> system:
>
> $ wget -S http://dev/ajax/shopping_list.php\?action=add\&SKU=ABC
> --15:48:41-- http://dev/ajax/shopping_list.php?action=add&SKU=ABC
>=> `shopping_list.php?action=add&SKU=ABC.1'
> Resolving dev... 192.168.0.30
> Connecting to dev|192.168.0.30|:80... connected.
> HTTP/1.1 200 OK
> Date: Mon, 11 Dec 2006 23:48:41 GMT
> Server: Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2
> PHP/5.2.0 with Suhosin-Patch mod_ruby/1.2.5 Ruby/1.8.5(2006-08-25)
> SVN/1.4.2
> mod_jk/1.2.15
> X-Powered-By: PHP/5.2.0
> Set-Cookie: PHPSESSID=WJ33PpO,nphiPAVxrbrWrQEnO5a; path=/
> Expires: Thu, 19 Nov 1981 08:52:00 GMT
> Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
> pre-check=0
> Pragma: no-cache
> Content-Length: 103
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Content-Type: application/xml
> Length: 103 [application/xml]
>
>
> And on the live server:
>
>
> $ wget -S http://test/ajax/shopping_list.php\?action=add\&SKU=ABC
> --15:48:26-- http://test/ajax/shopping_list.php?action=add&SKU=ABC
>=> `shopping_list.php?action=add&SKU=ABC'
> Resolving test... 192.168.0.31
> Connecting to test|192.168.0.31|:80... connected.
> HTTP request sent, awaiting response...
> HTTP/1.1 200 OK
> Date: Mon, 11 Dec 2006 23:48:26 GMT
> Server: Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.7e-p1
> SVN/1.3.2
> PHP/5.2.0 DAV/2
> X-Powered-By: PHP/5.2.0
> Content-Length: 103
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Content-Type: application/xml
> Length: 103 [application/xml]
>
>
> No session cookie! Note that the bodies of these two responses are
> identical as determined using diff. Also note that we have other sets
> of code on the test system which call session_start(), and a session
> cookie _is_ set, as it should be, and everything works fine. So it's
> not simply that the session module is broken or mis-configured on the
> test machine. Under most circumstances sessions work fine on both
> systems. This implies that there is something specific about the code
> that is running in the [page setup code] and/or [page output code]
> (refer to snippet above) that is causing session_start() to behave
> unusually. But again, the PHP code is identical, so it must be the
> code *in combination with* some other external difference between the
> two systems.
>
> The only differences between the two systems that could conceivably
> make sense (to my mind) in terms of this differing behavior are:
> Apache 2.0.59 and no Suhosin patch on the test machine, vs Apache
> 2.2.3 _with_ Suhosin patch on the development system (and I mention
> Suhosin only because it makes some cookie-related changes). There are
> other differences, but none that would appear that they should have
> this effect. Here are the configure commands used for each system:
>
> test system:
> ===
> './configure' '--with-mysql=/usr/local/mysql'
> '--with-pgsql=/usr/local/pgsql'
> '--with-gettext' '--with-xml' '--with-imap' '--with-imap-ssl'
> '--with-pspell'
> '--with-zlib' '--with-zlib-dir=/usr' '--with-bz2' '--with-ndbm'
> '--enable
Re: [PHP] Varying session behavior between 2 nearly identical Apache/PHP setups
Matthew North wrote:
> Hello All,
>
> I have an odd situation that I wonder if someone might have some
> insight on. The scenario is this:
>
> - Two FreeBSD systems running Apache+mod_php+others. We use one for
> development and the other for testing.
>
> - Each system is running PHP 5.2.0 with identical php.ini files.
>
> - On each system we have identical PHP code (confirmed to be identical
> by comparing cksum output) that looks essentially like this:
>
> === snip ===
> .
> . [page setup code]
> .
> trigger_error('['.session_id().']');
> if (needSession && !session_id())
^ is this a typo? or is this a constant?
>session_start();
> trigger_error('['.session_id().']');
> .
> . [page output code]
> .
> ?>
> === snip ===
>
> Errors are logged to file rather than the page, so the trigger_error()
> calls above result in entries similar to:
>
> [08-Dec-2006 16:59:23] PHP Notice: [] in /path/to/file.php on line 178
>
> [08-Dec-2006 16:59:23] PHP Notice: [GmQidWwShpRpHCGDiQrBr-Lk4ib] in
> /path/to/file.php on line 181
>
> So it appears a session is started.
>
> However, on the test system a session cookie is never sent back to the
> browser so the session cannot be restored, while on the development
> system everything works as it should (session cookie is set and
> session is therefore restored on each page load).
>
> Using 'wget -S', here are the response headers sent by the development
> system:
>
> $ wget -S http://dev/ajax/shopping_list.php\?action=add\&SKU=ABC
> --15:48:41-- http://dev/ajax/shopping_list.php?action=add&SKU=ABC
> => `shopping_list.php?action=add&SKU=ABC.1'
> Resolving dev... 192.168.0.30
> Connecting to dev|192.168.0.30|:80... connected.
> HTTP/1.1 200 OK
> Date: Mon, 11 Dec 2006 23:48:41 GMT
> Server: Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2
> PHP/5.2.0 with Suhosin-Patch mod_ruby/1.2.5 Ruby/1.8.5(2006-08-25)
> SVN/1.4.2
> mod_jk/1.2.15
> X-Powered-By: PHP/5.2.0
> Set-Cookie: PHPSESSID=WJ33PpO,nphiPAVxrbrWrQEnO5a; path=/
> Expires: Thu, 19 Nov 1981 08:52:00 GMT
> Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
> pre-check=0
> Pragma: no-cache
> Content-Length: 103
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Content-Type: application/xml
> Length: 103 [application/xml]
>
>
> And on the live server:
>
>
> $ wget -S http://test/ajax/shopping_list.php\?action=add\&SKU=ABC
> --15:48:26-- http://test/ajax/shopping_list.php?action=add&SKU=ABC
> => `shopping_list.php?action=add&SKU=ABC'
> Resolving test... 192.168.0.31
> Connecting to test|192.168.0.31|:80... connected.
> HTTP request sent, awaiting response...
> HTTP/1.1 200 OK
> Date: Mon, 11 Dec 2006 23:48:26 GMT
> Server: Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.7e-p1 SVN/1.3.2
> PHP/5.2.0 DAV/2
> X-Powered-By: PHP/5.2.0
> Content-Length: 103
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Content-Type: application/xml
> Length: 103 [application/xml]
>
your dev machine runs the with Suhosin-Patch, the live system does not -
that's a big difference.
> test system:
> ===
> './configure' '--with-mysql=/usr/local/mysql'
> '--with-pgsql=/usr/local/pgsql'
> '--with-gettext' '--with-xml' '--with-imap' '--with-imap-ssl'
> '--with-pspell'
> '--with-zlib' '--with-zlib-dir=/usr' '--with-bz2' '--with-ndbm'
> '--enable-dba'
> '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local'
> '--with-jpeg-dir=/usr/local' '--with-tiff-dir=/usr/local'
> '--with-png-dir=/usr/local' '--with-tidy' '--with-openssl'
> '--enable-sysvsem'
> '--enable-sysvshm' '--enable-dbase' '--enable-ftp' '--enable-memory-limit'
> '--enable-inline-optimization' '--disable-debug'
> '--with-apxs2=/usr/local/apache2/bin/apxs' '--prefix=/usr/local/php'
> '--with-config-file-path=/usr/local/php'
>
> development system:
>
> './configure' '--enable-versioning' '--enable-memory-limit'
> '--with-layout=GNU'
> '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all'
> '--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-reflection'
> '--enable-spl' '--program-prefix=' '--disable-path-info-check'
> '--with-apxs2=/usr/local/sbin/apxs' '--with-regex=php'
> '--with-zend-vm=CALL'
> '--prefix=/usr/local'
>
> I acknowledge that these aren't particularly similar, but they do not
> differ in any way that should cause this difference in behavior (do
> they?).
I can't pinpoint anything in particular but I would suggest it's worth
ruling out any possibility of the problem being due to the configure options
by rebuilding your dev php binary to be identical to the live version.
>
> The PHP modules loaded match between the two systems, with the
> exception of tidy which is enabled on the test machine and not enabled
> on the development system.
>
> And again, php.ini are identical between the systems.
if that is the case then first check to see if your webserver can actually write
session files to the designated d
Re: [PHP] Varying session behavior between 2 nearly identical Apache/PHP setups
Matthew North wrote: Hello All, I have an odd situation that I wonder if someone might have some insight on. The scenario is this: - Two FreeBSD systems running Apache+mod_php+others. We use one for development and the other for testing. - Each system is running PHP 5.2.0 with identical php.ini files. - On each system we have identical PHP code (confirmed to be identical by comparing cksum output) that looks essentially like this: === snip === === snip === Errors are logged to file rather than the page, so the trigger_error() calls above result in entries similar to: [08-Dec-2006 16:59:23] PHP Notice: [] in /path/to/file.php on line 178 [08-Dec-2006 16:59:23] PHP Notice: [GmQidWwShpRpHCGDiQrBr-Lk4ib] in /path/to/file.php on line 181 So it appears a session is started. However, on the test system a session cookie is never sent back to the browser so the session cannot be restored, while on the development system everything works as it should (session cookie is set and session is therefore restored on each page load). Using 'wget -S', here are the response headers sent by the development system: $ wget -S http://dev/ajax/shopping_list.php\?action=add\&SKU=ABC --15:48:41-- http://dev/ajax/shopping_list.php?action=add&SKU=ABC => `shopping_list.php?action=add&SKU=ABC.1' Resolving dev... 192.168.0.30 Connecting to dev|192.168.0.30|:80... connected. HTTP/1.1 200 OK Date: Mon, 11 Dec 2006 23:48:41 GMT Server: Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2 PHP/5.2.0 with Suhosin-Patch mod_ruby/1.2.5 Ruby/1.8.5(2006-08-25) SVN/1.4.2 mod_jk/1.2.15 X-Powered-By: PHP/5.2.0 Set-Cookie: PHPSESSID=WJ33PpO,nphiPAVxrbrWrQEnO5a; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Length: 103 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: application/xml Length: 103 [application/xml] And on the live server: $ wget -S http://test/ajax/shopping_list.php\?action=add\&SKU=ABC --15:48:26-- http://test/ajax/shopping_list.php?action=add&SKU=ABC => `shopping_list.php?action=add&SKU=ABC' Resolving test... 192.168.0.31 Connecting to test|192.168.0.31|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Mon, 11 Dec 2006 23:48:26 GMT Server: Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.7e-p1 SVN/1.3.2 PHP/5.2.0 DAV/2 X-Powered-By: PHP/5.2.0 Content-Length: 103 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: application/xml Length: 103 [application/xml] No session cookie! Note that the bodies of these two responses are identical as determined using diff. Also note that we have other sets of code on the test system which call session_start(), and a session cookie _is_ set, as it should be, and everything works fine. So it's not simply that the session module is broken or mis-configured on the test machine. Under most circumstances sessions work fine on both systems. This implies that there is something specific about the code that is running in the [page setup code] and/or [page output code] (refer to snippet above) that is causing session_start() to behave unusually. But again, the PHP code is identical, so it must be the code *in combination with* some other external difference between the two systems. The only differences between the two systems that could conceivably make sense (to my mind) in terms of this differing behavior are: Apache 2.0.59 and no Suhosin patch on the test machine, vs Apache 2.2.3 _with_ Suhosin patch on the development system (and I mention Suhosin only because it makes some cookie-related changes). There are other differences, but none that would appear that they should have this effect. Here are the configure commands used for each system: test system: === './configure' '--with-mysql=/usr/local/mysql' '--with-pgsql=/usr/local/pgsql' '--with-gettext' '--with-xml' '--with-imap' '--with-imap-ssl' '--with-pspell' '--with-zlib' '--with-zlib-dir=/usr' '--with-bz2' '--with-ndbm' '--enable-dba' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local' '--with-tiff-dir=/usr/local' '--with-png-dir=/usr/local' '--with-tidy' '--with-openssl' '--enable-sysvsem' '--enable-sysvshm' '--enable-dbase' '--enable-ftp' '--enable-memory-limit' '--enable-inline-optimization' '--disable-debug' '--with-apxs2=/usr/local/apache2/bin/apxs' '--prefix=/usr/local/php' '--with-config-file-path=/usr/local/php' development system: './configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-reflection' '--enable-spl' '--program-prefix=' '--disable-path-info-check' '--with-apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL' '--prefix=/usr/local' I acknowledge th
[PHP] Varying session behavior between 2 nearly identical Apache/PHP setups
Hello All, I have an odd situation that I wonder if someone might have some insight on. The scenario is this: - Two FreeBSD systems running Apache+mod_php+others. We use one for development and the other for testing. - Each system is running PHP 5.2.0 with identical php.ini files. - On each system we have identical PHP code (confirmed to be identical by comparing cksum output) that looks essentially like this: === snip === === snip === Errors are logged to file rather than the page, so the trigger_error() calls above result in entries similar to: [08-Dec-2006 16:59:23] PHP Notice: [] in /path/to/file.php on line 178 [08-Dec-2006 16:59:23] PHP Notice: [GmQidWwShpRpHCGDiQrBr-Lk4ib] in /path/to/file.php on line 181 So it appears a session is started. However, on the test system a session cookie is never sent back to the browser so the session cannot be restored, while on the development system everything works as it should (session cookie is set and session is therefore restored on each page load). Using 'wget -S', here are the response headers sent by the development system: $ wget -S http://dev/ajax/shopping_list.php\?action=add\&SKU=ABC --15:48:41-- http://dev/ajax/shopping_list.php?action=add&SKU=ABC => `shopping_list.php?action=add&SKU=ABC.1' Resolving dev... 192.168.0.30 Connecting to dev|192.168.0.30|:80... connected. HTTP/1.1 200 OK Date: Mon, 11 Dec 2006 23:48:41 GMT Server: Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2 PHP/5.2.0 with Suhosin-Patch mod_ruby/1.2.5 Ruby/1.8.5(2006-08-25) SVN/1.4.2 mod_jk/1.2.15 X-Powered-By: PHP/5.2.0 Set-Cookie: PHPSESSID=WJ33PpO,nphiPAVxrbrWrQEnO5a; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Length: 103 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: application/xml Length: 103 [application/xml] And on the live server: $ wget -S http://test/ajax/shopping_list.php\?action=add\&SKU=ABC --15:48:26-- http://test/ajax/shopping_list.php?action=add&SKU=ABC => `shopping_list.php?action=add&SKU=ABC' Resolving test... 192.168.0.31 Connecting to test|192.168.0.31|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Mon, 11 Dec 2006 23:48:26 GMT Server: Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.7e-p1 SVN/1.3.2 PHP/5.2.0 DAV/2 X-Powered-By: PHP/5.2.0 Content-Length: 103 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: application/xml Length: 103 [application/xml] No session cookie! Note that the bodies of these two responses are identical as determined using diff. Also note that we have other sets of code on the test system which call session_start(), and a session cookie _is_ set, as it should be, and everything works fine. So it's not simply that the session module is broken or mis-configured on the test machine. Under most circumstances sessions work fine on both systems. This implies that there is something specific about the code that is running in the [page setup code] and/or [page output code] (refer to snippet above) that is causing session_start() to behave unusually. But again, the PHP code is identical, so it must be the code *in combination with* some other external difference between the two systems. The only differences between the two systems that could conceivably make sense (to my mind) in terms of this differing behavior are: Apache 2.0.59 and no Suhosin patch on the test machine, vs Apache 2.2.3 _with_ Suhosin patch on the development system (and I mention Suhosin only because it makes some cookie-related changes). There are other differences, but none that would appear that they should have this effect. Here are the configure commands used for each system: test system: === './configure' '--with-mysql=/usr/local/mysql' '--with-pgsql=/usr/local/pgsql' '--with-gettext' '--with-xml' '--with-imap' '--with-imap-ssl' '--with-pspell' '--with-zlib' '--with-zlib-dir=/usr' '--with-bz2' '--with-ndbm' '--enable-dba' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local' '--with-tiff-dir=/usr/local' '--with-png-dir=/usr/local' '--with-tidy' '--with-openssl' '--enable-sysvsem' '--enable-sysvshm' '--enable-dbase' '--enable-ftp' '--enable-memory-limit' '--enable-inline-optimization' '--disable-debug' '--with-apxs2=/usr/local/apache2/bin/apxs' '--prefix=/usr/local/php' '--with-config-file-path=/usr/local/php' development system: './configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-reflection' '--enable-spl' '--program-prefix=' '--disable-path-info-check' '--with-apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL' '--prefix=/usr/local' I acknowledge that these aren't particularly similar
