ini_set() not working as expected

[yawnmoth]

When running the following code I get a warning:

<?
ini_set('session.use_cookies',0);
?>
random text
<?
session_start();
?>

The output / warning I'm getting is this:

random text
Warning: session_start(): Cannot send session cache limiter - headers
already sent (output started at /path/to/file.php:5) in
/path/to/file.php on line 6

Shouldn't the fact that I'm setting session.use_cookies to 0, via
ini_set, prevent this error from taking place?

[Paul Lautman]

yawnmoth wrote:

When running the following code I get a warning:

<?
ini_set('session.use_cookies',0);

random text
<?
session_start();

The output / warning I'm getting is this:

random text
Warning: session_start(): Cannot send session cache limiter - headers
already sent (output started at /path/to/file.php:5) in
/path/to/file.php on line 6

Shouldn't the fact that I'm setting session.use_cookies to 0, via
ini_set, prevent this error from taking place?

The headers are sent as soon as some output is sent. In your case you are
sending a blank followed by the text random text, before doing the
session_start().

[yawnmoth]

Paul Lautman wrote:

yawnmoth wrote:
<snip>
The headers are sent as soon as some output is sent. In your case you are
sending a blank followed by the text random text, before doing the
session_start().

Why isn't the ini_set preventing that, though? I don't want PHP to
propogate PHPSESSID via $_COOKIE - I want it to propogate through
$_GET.

I could just do it via .htaccess or php.ini, but doing so would still
leave me wondering why ini_set doesn't work. As far as I know, it
should, yet it doesn't, and I'd like to know why.

[Kimmo Laine]

"yawnmoth" <te*******@yahoo.com> wrote in message
news:11*********************@j55g2000cwa.googlegro ups.com...

Paul Lautman wrote:

yawnmoth wrote:
<snip>
The headers are sent as soon as some output is sent. In your case you are
sending a blank followed by the text random text, before doing the
session_start().

Why isn't the ini_set preventing that, though? I don't want PHP to
propogate PHPSESSID via $_COOKIE - I want it to propogate through
$_GET.

I could just do it via .htaccess or php.ini, but doing so would still
leave me wondering why ini_set doesn't work. As far as I know, it
should, yet it doesn't, and I'd like to know why.

Ini_set doesn't work that way because it's never meant to work that way in
the first place. 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. 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.

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.

--
"ohjelmoija on organismi joka muuttaa kofeiinia koodiksi" -lpk
sp**@outolempi.net | Gedoon-S @ IRCnet | rot13(xv***@bhgbyrzcv.arg)

[yawnmoth]

Kimmo Laine wrote:

"yawnmoth" <te*******@yahoo.com> wrote in message
news:11*********************@j55g2000cwa.googlegro ups.com...
<snip>
Ini_set doesn't work that way because it's never meant to work that way in
the first place. 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. 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.

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.

Here's another question, then. Why does it also not work when my
..htaccess has the following line added to it?:

php_flag session.use_cookies off

Does this mean that php_admin_flag has been set to on in an earlier
directory or am I doing something wrong?

[Paul Lautman]

Kimmo Laine wrote:

"yawnmoth" <te*******@yahoo.com> wrote in message
news:11*********************@j55g2000cwa.googlegro ups.com...

Paul Lautman wrote:

yawnmoth wrote:
<snip>
The headers are sent as soon as some output is sent. In your case
you are sending a blank followed by the text random text, before
doing the session_start().

Why isn't the ini_set preventing that, though? I don't want PHP to
propogate PHPSESSID via $_COOKIE - I want it to propogate through
$_GET.

I could just do it via .htaccess or php.ini, but doing so would still
leave me wondering why ini_set doesn't work. As far as I know, it
should, yet it doesn't, and I'd like to know why.

Ini_set doesn't work that way because it's never meant to work that
way in the first place. 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. 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.

But the manual does say: "If you are using cookie-based sessions, you must
call session_start() before anything is outputted to the browser."

Which implies that if you are not using cookie-based sessions, then you can
call session_start() after sending output to the browser.

[yawnmoth]

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.

[yawnmoth]

yawnmoth wrote:

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.

Never mind. Set-Cookie isn't the only header session_start sends out,
apparently...