ID: 34542
User updated by: marcus dot uy at virtualthinking dot com
Reported By: marcus dot uy at virtualthinking dot com
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: WinXP Pro
PHP Version: 5.1.0RC4, 5.2.0
New Comment:
mod_security removed. Behaviour of PHP is still the same as my
previous post.
I have tested the same php.ini file on a separate linux server (with
path names adjusted for linux) that I own and it works with
register_long_arrays=off in the expected manner as documented.
The same settings on windows fail to work as noted earlier.
I cannot verify this, but is there some internal reference or
dependency in the session subsystem that uses the old long array
vars/buffer as the input source for the data that is written to the
session file?
Hence:
$_SESSION => can show up during the run
...but...
$HTTP_SESSION_VAR => written to disk, and thus empty
Any chance? Was discussing fault scenarios with a friend and this came
up as a plausible case that would result in this kind of oddity (a
difference in how the windows and linux compilers work might account
for the difference in behaviour on different platforms???).
Previous Comments:
------------------------------------------------------------------------
[2006-11-29 10:08:15] [EMAIL PROTECTED]
First of all, please remove/disable mod_security.
------------------------------------------------------------------------
[2006-11-29 01:19:02] marcus dot uy at virtualthinking dot com
Dev/Tester. Please tell us what your setup is. Mine is as follows:
XPPro SP2, Apache 2.2.3, mod_security 2.0.4, PHP5.2.0
Settings as per recommended for performance.
Sessions configured to use URL, NOT cookies.
Sessions are being stored in C:\temp\sessiondata
When register_long_arrays is set to "off", Session data is created in
the script on first execute (print_r($_SESSION), dumps correctly), but
not saved to session file (e.g. sess_34r234r234r234r234r234, is
zero-length)
When register_long_arrays is set to "on", Session data is created in
the script on first execute (print_r($_SESSION), dumps correctly), and
is saved to session file (e.g. sess_34r234r234r234r234r234, is
non-zero-length)
The code does not use *any* HTTP_*_VARS... anywhere. Only $_ENV,
$_GET, $_POST, and $_SESSION. $_COOKIES is *not* used anywhere.
------------------------------------------------------------------------
[2006-11-28 22:48:18] [EMAIL PROTECTED]
Cannot reproduce, doesn't matter what is the value of
register_long_arrays. Please make sure you don't have any firewalls or
zend_extension's which might affect it.
------------------------------------------------------------------------
[2006-11-28 22:35:54] marcus dot uy at virtualthinking dot com
This bug is still there in 5.2.0.
BTW My environment does not use session cookies. I use the session
passed via URL. The reason is that my code overcomes the problems
associated with URL hijacking in-code, rather than depending on session
cookies that could also get hijacked.
The error stands.
I swear that it is real.
And, frankly, there seems to be many, many scripts and users that are
reporting similar session issues. I don't think that we could all be
wrong.
------------------------------------------------------------------------
[2005-12-11 14:47:31] [EMAIL PROTECTED]
This still doesn't happen.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/34542
--
Edit this bug report at http://bugs.php.net/?id=34542&edit=1
