What is your register_globals setting?

Derick

Both servers got register_globals = On.
On the 4.1.0 server i run with a php.ini that originates from the 4.0.5 release.

--niklas

This bug is in 4.1.1 aswell

Clarification. 
Which save handler are you using files or user?

No feedback was provided for this bug, so it is being suspended.
If you are able to provide the information that was requested,
please do so and change the status of the bug back to "Open".

I notice this too under 4.1.2.  unset($var) doesn't unregister $var from the session

FWIW, this is with Linux 2.4.6-pre6, and I'm using the default files for session storage.

- Colin

AFAIK, this is fixed in CVS and PHP 4.2.0RC1.
Please test RC1 from: http://www.php.net/~derick/
and if it doesn't work, latest snapshot from http://snaps.php.net/

Using 4.2.0.RC2 this behavior still there, you can check with these scripts:
## i2.php
<?php
session_start();
$counter = 1;
session_register("counter");
header("Location: /i.php");
?>

## i.php
<?php
session_start();
$counter = 0;
### uncomment this to see the difference
# session_unregister("counter");
session_register("counter");
unset($counter);
$counter = 4;
session_register("counter");
header("Location: /i1.php");
?>

## i1.php
<?php
session_start();
print $counter;

?>

And then open http://host/i2.php in browser window.

Expected output - 4, but I get 0.

This is very strange. I have redirect and session works as it shold. 

Could you try register_globals=Off to see if it works?

With register_globals = off I get nothing, i.e. no number, just newline, with or without session_unregister("counter"). Seems like $counter does not exist at all.

FYI, with 4.0.5 my example scripts gives expected result - 4 with register_globals = on, and the same nothing with register_globals = off.

4.2.0 final still has the problem. And it is a problem, not an imagination.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Having a SetCookie and a Redirect in the same response causes unpredictable behaviour and will be browser-dependant.  I'd suggest not relying on this.  PHP does send both, so unless you can somehow show us an example of PHP not actually sending both the Location and the SetCookie then I don't see how this is a PHP issue.

I see you miss the point. I have made that example of three scripts with redirects to easy things. You can equaly put links into scripts and then click them manualy with the same effect. All Set_Cookie and Redirect headers look fine. Take a look at the first message here from niklas-phpbugs@alberth.com. I can only speculate why this does not work in 4.1 or 4.2: when you register variable with session_register php it puts a referense to variable. When unset function  unsets variable, session variable still hold reference to old variable, though it does not exist anymore. When you try to reregister variable with session_register it thinks that that variable already registered, and does nothing. So whaterver new value you assign id does not reach session module, even at exit of the script. But in theory session should reference to the name of variable not variable itself, and if variable is gone in context so must session registered one. And if you use session_unregister in the same script as unset, you would get correct result. (see ### uncomment this to see the difference # session_unregister("counter");).

I don't want to insult anyone but I am amazed that such simple bug have not been fixed several monthts yet.

I didn't miss the point.  You should probably have stated that your example showed the problem with simple hrefs as well.  I scan things quickly and if an obvious thing such as trying to do a setcookie and a redirect in the same request is there, I comment on that and move on.

What you are seeing is a side-effect of having $HTTP_SESSION_VARS['counter'] and $_SESSION['counter'] and $counter all be references to the same data.  unset($counter) only removes one reference.  It would be inconsistent to make unset() remove all references, and the most common usage is simply $counter = new_value which works correctly.  Doing a second session_register() on the same variable doesn't currently do anything since it is already registered unless of course you have called session_unregister on it.  So in summary, I think this is a fringe case that needs documenting and not necessarily fixing unless someone can come up with a clean and consistent fix.

So please at least document that such fringe case which works in 4.0.5, 4.0.6 does not work in 4.1, 4.2, and scripts need code changes in order to run as expected on 4.1, 4.2.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".