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@[...].com>  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