Sessions are generally persisted using cookies so this should be an obvious side-effect of disabling them.

If this is a problem for your application, one common solution (besides telling your user to enable cookies) is to put the session ID in the URL unless/until you've detected that cookies are enabled. Which is risky. See also the session.use-trans-sid* INI setting where PHP will automatically rewrite the URLs for you.

* http://php.net/manual/en/session.configuration.php#ini.session.use-trans-sid

Sorry, but this answer is a bit "stupid":

- It's a bug, because session-handling does not work as it should.
- It's a bug, because, if you set session_id($_REQUSET[PHPSESSID])) manually, it works.
- If it is a risk to send the session per URL, it shouldn't be possible to do this at all (any hacker knows, how to handle cookies, even it's described other way in the documentation).
- It's not right IMHO to force a user to set cookies (I don't like them, and it worries me, if a page forces me to use them. Same for javascript.). My pages should work in every case.

So if you want to see this effect: http://test.rtin.ws

BTW. this error occured a few yeas ago (somewhere in PHP 4).

Workaround: Set session_id() manually.

But it's still a bug

>It's a bug, because session-handling does not work as it should.
You should mention that to the people who design the HTTP standard. Make sure you CC the developers of browsers so that they know not to allow users to change configuration settings that may break your website.

>It's a bug, because, if you set session_id($_REQUSET[PHPSESSID])) manually, it
>works.
What are your session.* INI settings? Specifically session.use_only_cookies.

>If it is a risk to send the session per URL, it shouldn't be possible to do
>this at all
It's definitely risky. Which is why PHP doesn't use that behavior unless you go out of your way to enable it.

>It's not right IMHO to force a user to set cookies
You can say that all you want, it doesn't change the technical problem: without the URL or a cookie, PHP can't know which session to use for a request. Or maybe you have a suggestion for how to do that?

> "You should mention that to the people who design the HTTP standard."
- What does HTTP standard has to do with PHP-session-handling?

> "What are your session.* INI settings? Specifically session.use_only_cookies."
- See http://test.rtin.ws (phpinfo() is now included, session.use_only_cookies is "on")

> "It's definitely risky..."
- Security discussion has not to be in bug-reporting. 

> "Which is why PHP doesn't use that behavior unless you go out of your way to enable it."
- Yep, and then this bug occures.

> "You can say that all you want, it doesn't change the technical problem:"
- That's the point, so please, don't have a look to my favoutity settings or security risks: Please fix the technical problem.

> "without the URL or a cookie, PHP can't know which session to use for a request. Or maybe you have a suggestion for how to do that?"
- if PHP sets a cookie, session-request will be read from there.
- if you don't use "session_name();" PHP is looking for $_REQUEST[PHPSESSID]
- if you use "session_name('my_name');" PHP is looking for $_REQUEST['my_name']

All in all: in previous versions session handling always worked in this constallation (as I wrote, somewhere in PHP4 this error occured too). You can use my simple script to test it for yourself.
I don't want to discuss any longer this weird cookie/security stuff. For me I have a workaround (setting session_id() manually) and 99% won't recognize this bug, because they have cookies activated.

This is clearly a technical bug in PHP-session handling (a friend of mine tested it with his own server and the same error occures, and I bet, that if you try it on your own server, it will occure too).

A security discussion does not fix this bug.

>What does HTTP standard has to do with PHP-session-handling?
Everything. Why do you think the cookie mechanism exists in the first place? Because HTTP didn't provide a secure (relatively) method of maintaining state with a website - and arguably still doesn't.

>session.use_only_cookies is "on"
Great. Find out what that setting means and you should realize why you're having your disappearing SID problem (when the PHPSESSID is passed via the URL, that is).
http://php.net/manual/en/session.configuration.php

Then I asked for suggestions on how to keep sessions working when cookies are not available and the URL isn't an option, but I think you misunderstood my question.

Either you need to adjust your session configuration, as I've hinted at, or you are stuck because there is nothing PHP can do. And neither of those qualify as bugs with PHP's behavior.

I've said all that I can, which is more than this bug tracking system should be used for anyways. If you need someone to provide you with a different explanation of what's going on, try http://php.net/support.php

I tried to set test it with session.use_only_cookies is "off" (canging the value in php.ini from "1" to "0", restart the server, but in php_info() it appears still as "on".

However; I set session_id() manually to the value given by the $_REQUEST.

Make sure you're editing the right php.ini, and you're already restarting the server. Past experience has shown me that if the problem persists then there's some sort of server- or environment-specific situation to blame.

Meanwhile, use_only_cookies can be set at runtime so you can at least test that.

<?php

ini_set("session.use_only_cookies", 0);

session_name('test');
session_start();

echo '<a href="?'.SID.'">test</a>';
?>

session_name('test');
session_start();
echo '<a href="?'.SID.'">test</a>

This code is wrong.

session_name('test');
session_start();
echo '<a href="?test='.SID.'">test</a>

is correct for trans_sid usage.

BTW, trans sid has rather serious bug now. I strongly discourage using it...

SID includes the name. http://php.net/manual/en/session.constants.php