Posted by yawnmoth on 06/09/06 05:00

Kimmo Laine wrote:
> "yawnmoth" <terra1024@yahoo.com> wrote in message
> news:1149751294.421301.16080@j55g2000cwa.googlegroups.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.

[Back to original message]