Thanks to all who responded. Your responses reconfirmed that there
must be some configuration difference between the two so I grudgingly
re-examined everything, and esp. phpinfo() output.
Turns out the test machine had a default (at build time) of
'output_buffering = 0'. Although the two machines shared exact
php.ini, the test machine was effectively doing no output buffering
while the development system was. Explicitly changing this setting to
4096 'solved' the problem.
However, this wasn't the whole story. Turning on output buffering
could only solve the problem if we were doing some out-of-band output
before the session headers were sent that was now being buffered.
Sure enough I found some code that was outputting some response text
before session_start() was called. On the test machine this output
was being buffered until after session_start(), so no apparent problem
existed.
I think the lesson here is, if you're missing headers in your output,
assume first that it's because you've started body output before the
headers in question were sent. If I'd made that assumption earlier I
probably would have saved hours on this bug! (otoh, doesn't that
situation normally result in a PHP warning? where'd that go? oh
well...).
- Matt
On 12/12/06, Matthew North <northmh@xxxxxxxxx> 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 ===
<?php
.
. [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-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?).
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.
What could explain this difference in behavior?
Thanks,
Matthew H. North
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
