Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

Thanks tony but like I said -

"I would appreciate a work-around if anyone can supply one as I use an ISP and can't update PHP."

If I could I'd upgrade (My development system uses the latest release) but like many thousands of sites I can't upgrade my live site. Perhaps a modification of the versions drop-down to this bug system to take this into account would help others too.

Also CVS would be out of the question for a live eCommerce site anyway. I would only consider stable releases marked as such. Public access to CVS is a massive mistake. Huge.

Whatever happens I'm going to need a work-around for this.
I could use suggestions - 
thanks

nigel.

You don't have to touch a working site or a working Apache.
PHP can be installed locally or using different Apache on different port.

Technically I'm intregued but its way over the top surely tony?

There must be a better way to prevent a spurious sessionID than having two copies of everything running? I doubt my ISP would like the idea too much either...

Do we know where PHP gets the host value to put in the PHPSESSID in the first place?  Could I perhaps just change the value in there before the first session is created ?

(I did try changing $_SERVER['HTTP_HOST'] but that didnt do it.)

nigel.

Nigel, I'm not sure wether I understand your issue, but it seems to be a bogus.

When accessing "example.com", the same session will be available at "www.example.com".

Hoewever. When accessing "www.example.com", the sessions cookie set there, is outside the scope for "example.com" which is fixed by the session_set_cookie_params function call. Which takes similar parameters as setcookie. With this function you should set the cookie domain scope to "example.com" instead of the default current domain.

If the PHPSESSID cookie would be correct for both domains but the session is just "lost" (which prob. trigger php to regenerate a session id) you should check what "session_save_path" both sites use. Your server may be using different save paths for both subdomains.

Good luck and regards,
Eric

No eric - the issue is neither complicated nor is it bogus.

Try the simple code I placed in the first message and you will see 2 sessions started if the site in not originally accessed using www. pre-pended to the address instead of one session.

QUOTE:
When accessing "example.com", the same session will be available at "www.example.com".

This is not true and is exactly what I'm reporting.

Connect to  "example.com" and the second file above (store.php) will have a different session to the first file.

This is really a support issue that should be aired in the php-general mailing list, but I'll drop a couple of hints here anyway.

(i) if you're relying on cookies to pass the session-id, that cannot work as cookies set at example.com can't be read at www.example.com

(ii) PHP's URL-rewriter also doesn't work, for similar security reasons, for URLs that are at a different apparent domain (nor, come to that, for any URL in header()!).

(iii) therefore you have to pass it manually as either a GET or a POST parameter; session_name() and session_id() are useful here.

"This is really a support issue that should be aired in the php-general
mailing list, but I'll drop a couple of hints here anyway."

How can it be? This is a bug and a big one affecting sessions in an obscure and difficult to track down manner. 

"(i) if you're relying on cookies to pass the session-id, that cannot
work as cookies set at example.com can't be read at www.example.com"

1. I am not relying on cookies to do anything.I dont set any cookies at all. I am relying on PHP to generate a single session-ID for a single session.
It does not - that is a bug.That is what I've reported.

2. example.com and www.example.com are the same domain.

A browser enters example.com and navigates to the first piece of code listed above - this generates one session.

This code sends them to the second page on the same site/domain (as you can see) and this generates a second session. 
This is clearly incorrect behaviour as in session 1 PHP thinks the host is example.com and in session 2 (which shouldnt even exist) it thinks the host is www.example.com.
PHP has incorrectly decided it's now using a different host.

Entering this domain at any page with www.example.com then navigating to the code above generates one session ID and correctly echoes the variable.
Now close your browser and re-start it. 
Entering the same page with example.com then navigating to the code above generates 2 sessions and 2 session-id's and obviously looses the variable as a result.

It couldnt be any clearer that this is not correct behaviour.

Try the code.Look at the value of "HOST" in PHPSESSID and the number of PHPSESSID's generated each time.
 
"session_set_cookie_params function call. Which takes similar parameters
as setcookie. With this function you should set the cookie domain scope
to "example.com" instead of the default current domain."

Thanks - I'll give that a go of course - but my expectation is by doing this the bug will simply operate in reverse?

But normally nobody needs to do this before every request and before every session_start() so if thats the fix - its another indication of a bug not a support issue. 

"(ii) PHP's URL-rewriter also doesn't work, for similar security reasons,
for URLs that are at a different apparent domain (nor, come to that, for
any URL in header()!).
"

I would neither want nor expect it to - that is not the issue.

"(iii) therefore you have to pass it manually as either a GET or a POST
parameter; session_name() and session_id() are useful here."

There should be no requirement to pass anything.That's the entire purpose of PHPSESSID in the first place!

1 connection to 1 host should generate 1 session not 2. There should be no need to create extra sessions and pass names or id's about. The second session shouldnt exist.

PHP needs to be corrected so it doesn't think example.com and www.example.com are different host domains.

Try the perfectly correct code above - and you tell me what you get for each attempt.

I have reverted this bug status back from bogus to open.

I also suggest it be considered "critical" and presumably pertaining to all OS's and all releases of PHP ?

Either set your session.cookie_domain to mysite.com or redirect mysite.com to www.mysite.com before you start the session.  There is no bug here.

... and if you post your problem in php-general, as suggested before, I (and no doubt others) will be delighted to explain at length.