By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,934 Members | 1,527 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,934 IT Pros & Developers. It's quick & easy.

SESSION error -> Your script possibly relies on a session side-effectwhich existed until PHP 4.2.3.

P: n/a
Hi group,

Does anybody know what causes the following Warning?

__________________________________________________
Warning: Unknown(): Your script possibly relies on a session side-effect
which existed until PHP 4.2.3. Please be advised that the session
extension does not consider global variables as a source of data, unless
register_globals is enabled. You can disable this functionality and this
warning by setting session.bug_compat_42 or session.bug_compat_warn to
off, respectively. in Unknown on line 0
__________________________________________________

Since the whole projectcode is way too much to post here, I hope
somebody has a clue, so I know where to start looking.

It only happens on one Mac here in the office, and only at a certain page.
All other Sessionlogic works as intended, also on the Mac.

The server:
Apache1.3/PHP 4.3,
session.autostart is on.
Sessionstorage is files.
No register globals (of course).

The scripts use only code like this:
$_SESSION["bla"] = "something";
No session_register ancient stuff.

The Mac in question accepts cookies.
The warning is reproducable.

I work a lot with sessions, and this is the first time I see this
warning on my own system.

Can anybody help me?
Where to start bughunting?

I hate the fact the Warning says: "in Unknown on line 0", which isn't
helpful at all of course.

Regards,
Erwin Moller
Jun 2 '08 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Erwin Moller schreef:

<snip>

Correction: It happens on all systems (also Windows on FF).
(luckily)

Looking into it myself now, but didn't find a thing yet. :-/

Erwin Moller
Jun 2 '08 #2

P: n/a
On Tue, 29 Apr 2008 13:33:19 +0200, Erwin Moller
<Si******************************************@spam yourself.comwrote:
Erwin Moller schreef:

<snip>

Correction: It happens on all systems (also Windows on FF).
(luckily)

Looking into it myself now, but didn't find a thing yet. :-/

Erwin Moller
Does this trigger it:
<?php
ini_set('session.bug_compat_warn',1);
ini_set('session.bug_compat_42',1);
session_start();
$_SESSION['foo'] = NULL;
$foo = "foo";
?>

If so, the warning will _not_ appear:
- if $_SESSION['foo'] exists and is not null
- there's no global variable named $foo

Lousy error message BTW. Just act as usual I'd say, turn of
session.bug_compat_warn & session.bug_compat_42.
--
Rik Wasmus
Jun 2 '08 #3

P: n/a
Rik Wasmus schreef:
On Tue, 29 Apr 2008 13:33:19 +0200, Erwin Moller
<Si******************************************@spam yourself.comwrote:
>Erwin Moller schreef:

<snip>

Correction: It happens on all systems (also Windows on FF).
(luckily)

Looking into it myself now, but didn't find a thing yet. :-/

Erwin Moller

Does this trigger it:
<?php
ini_set('session.bug_compat_warn',1);
ini_set('session.bug_compat_42',1);
session_start();
$_SESSION['foo'] = NULL;
$foo = "foo";
?>
Yes, it does trigger it.
(I had to remove session_start() because that added another warning
since I had autostart on on the machine)
>
If so, the warning will _not_ appear:
- if $_SESSION['foo'] exists and is not null
- there's no global variable named $foo
Aha, now I get the error.

Let me summarize: PHP is wasting time by checking if I use variablenames
in my script that exists as a key in the $_SESSION?
Jeeez... What a waste of CPU resources. :P

I am surprised I never had this warning before, since I NEVER paid any
attention to similarity in names in SESSION and my scriptvars. ;-)
>
Lousy error message BTW. Just act as usual I'd say, turn of
session.bug_compat_warn & session.bug_compat_42.
Thanks Rik for your clear and fast reply.

And yes, very lousy description of the error/warning indeed.

I'll immediately change the php.ini to surpress these nonsense warnings.

Thanks.

Erwin Moller
Jun 2 '08 #4

P: n/a
On Tue, 29 Apr 2008 14:18:50 +0200, Erwin Moller
<Si******************************************@spam yourself.comwrote:
Rik Wasmus schreef:
>On Tue, 29 Apr 2008 13:33:19 +0200, Erwin Moller
<Si******************************************@spa myourself.comwrote:
>>Erwin Moller schreef:

<snip>

Correction: It happens on all systems (also Windows on FF).
(luckily)

Looking into it myself now, but didn't find a thing yet. :-/

Erwin Moller
Does this trigger it:
<?php
ini_set('session.bug_compat_warn',1);
ini_set('session.bug_compat_42',1);
session_start();
$_SESSION['foo'] = NULL;
$foo = "foo";
?>

Yes, it does trigger it.
(I had to remove session_start() because that added another warning
since I had autostart on on the machine)
Euhm, doh, yes offcourse :).
> If so, the warning will _not_ appear:
- if $_SESSION['foo'] exists and is not null
- there's no global variable named $foo

Aha, now I get the error.

Let me summarize: PHP is wasting time by checking if I use variablenames
in my script that exists as a key in the $_SESSION?
Jeeez... What a waste of CPU resources. :P
Indeed, what a waste. I suspect turning of session.bug_compat_42 will halt
that checking.
I am surprised I never had this warning before, since I NEVER paid any
attention to similarity in names in SESSION and my scriptvars. ;-)
As you shouldn't have to :) (and global variables should be few
offcourse...)
> Lousy error message BTW. Just act as usual I'd say, turn of
session.bug_compat_warn & session.bug_compat_42.

Thanks Rik for your clear and fast reply.

And yes, very lousy description of the error/warning indeed.

I'll immediately change the php.ini to surpress these nonsense warnings.
Nonsense indeed, amen.
--
Rik Wasmus
Jun 2 '08 #5

P: n/a
Rik Wasmus schreef:

<snip>
>I'll immediately change the php.ini to surpress these nonsense warnings.

Nonsense indeed, amen.
Hi Rik,

I include an ini_set routine in all my projects these days, and added
them over there. Now the warning is gone. :-)

And now for the fun part:
session.bug_compat_42 or session.bug_compat_warn both don't exists in my
php.ini. sigh.
Am I expected to just add them?

I am used to changing ini values, but never added new ones before.
(and this is a productionserver)
Do you think I could just add them, kick Apache, and be done with it?

Regards,
Erwin Moller
Jun 2 '08 #6

P: n/a
On Tue, 29 Apr 2008 15:00:35 +0200, Erwin Moller
<Si******************************************@spam yourself.comwrote:
Rik Wasmus schreef:

<snip>
>>I'll immediately change the php.ini to surpress these nonsense
warnings.
Nonsense indeed, amen.

Hi Rik,

I include an ini_set routine in all my projects these days, and added
them over there. Now the warning is gone. :-)

And now for the fun part:
session.bug_compat_42 or session.bug_compat_warn both don't exists in my
php.ini. sigh.
Am I expected to just add them?

I am used to changing ini values, but never added new ones before.
(and this is a productionserver)
Do you think I could just add them, kick Apache, and be done with it?
Sure, lots of values aren't specifically set in many normal php.ini, so
they just take the default (which sadly in this case would be "on" for
both of them). Just set them & reload Apache.
--
Rik Wasmus
Jun 2 '08 #7

P: n/a
Rik Wasmus schreef:
On Tue, 29 Apr 2008 15:00:35 +0200, Erwin Moller
<Si******************************************@spam yourself.comwrote:
>Rik Wasmus schreef:

<snip>
>>>I'll immediately change the php.ini to surpress these nonsense
warnings.
Nonsense indeed, amen.

Hi Rik,

I include an ini_set routine in all my projects these days, and added
them over there. Now the warning is gone. :-)

And now for the fun part:
session.bug_compat_42 or session.bug_compat_warn both don't exists in
my php.ini. sigh.
Am I expected to just add them?

I am used to changing ini values, but never added new ones before.
(and this is a productionserver)
Do you think I could just add them, kick Apache, and be done with it?

Sure, lots of values aren't specifically set in many normal php.ini, so
they just take the default (which sadly in this case would be "on" for
both of them). Just set them & reload Apache.
Thx again.
Worked like a charm. :-)

Regards,
Erwin Moller
Jun 2 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.