Kimmo Laine wrote:
"yawnmoth" <te*******@yahoo.com> wrote in message
news:11*********************@j55g2000cwa.googlegro ups.com...
<snip>It doesn't affect the way headers and body are sent. once
you start sending the body, session information cannot be sent, headers were
already sent.
Rereading this... I'm not asking it to affect the way the headers and
the body are sent - I'm asking it to not send headers when sending the
session information. Headers are only necessary, after all, if cookies
are being set, and I don't want cookies to be set, at all.
When you close the first php tag, the random text is echoed
out to client. That's when headers are sent and sending body begins.
I'm not disputing that.
After ini_set you might want to call ob_start() if you want the output to be
buffered. Then you should be able to set session variables later because
output doesn't begin until ob_flush() is called or page ends.
I don't want to buffer the output, though. I just don't want
session_start to use $_COOKIE.
In a similar vein, something that's always bugged me about PHP's
documentation regarding sessions is how it recommends you unset
$_SESSION vars before calling session_destory. As I understand it,
session_destory makes $_SESSION unavailable the next time the script is
called. During the current execution of it, however, the $_SESSION
vars still exist. unsetting the $_SESSION vars makes them unavailable
to the current execution of the script. But why does it matter? If
they don't need to be called after a certain point, how about just not
calling them? Unsetting can save memory, I suppose, but then why
aren't $_GET and $_POST unset after they've been assigned to variables
(if they are)?
All in all, php.net's documentation on sessions just strikes me as poor
compared to the rest of it.