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 ===
> <?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
>
>
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
