Your problem probably is including the miec.php from the .shtml
document.  Does the .shtml document send any output to the browser before
including your .php script?  If so, you're not going to be able to send
any cookies from the .php script.  Once any standard output makes it to
the browser (including any leading whitespace), no more headers can be
sent to the browser.  PHP sends cookies to the browser as header data.
Hence, if your .shtml document has any output before your .php document is
included, your session cookie cannot be sent.

        ~Chris                           /"\
                                         \ /     September 11, 2001
                                          X      We Are All New Yorkers
                                         / \     rm -rf /bin/laden

On Mon, 12 Nov 2001, Christian Dechery wrote:

> I've recently had a problem with sessions, and came up with a problem that
> apparently has no solution...
> I want to understand why EXACTLY it does't work...
>  From what I understand about sessions (reading PHP Docs), cookies are
> default and URLs holding the session_id are used if the cookies can be used
> to get the current session_id right?
> So if, there's a cookie indicating a session, PHP will detect it and the
> session will work beatifully..
> If when a session is created, a cookie cannot be set, then the URLs come
> into play.. right?
> -- I'm I right so far? --
> So, I can only presume, that whenever I can see those URLs with
> session_ids, this means that no cookie was created... and if one of those
> URLs is clicked, the session will persist, since the URL is carrying the
> session_id.
> Well, now to the problem with no solution... I've described it here on the
> list a couple of times... sorry if this is getting too annoying.
> 1 - I have a PHP script, that uses sessions, it's called miec.php
>       miec.php uses both cookies and sessions... the cookie holds the
> user_id and the session holds an array of every
>       product the user has seen, so they won't repeat... of course, the
> session only gets initialized if the cookie with the
>       user id is found... if not, a login form is shown...
> 2 - I have a html file, demo.shtml, which with SSI includes miec.php
>       The inclusion works fine, even the cookie with the user id gets
> detected and the username is shown as expected
> Now, the problem. If I run miec.php solo on the browser, everything works
> perfectly.
> But if I call demo.shtml, something goes wrong, and I want to know what.
> When demo.shtml is called, the cookie works (the user id is detected) and
> the session gets started. I can see the URLs with the session id AND the
> session file in my webserver. The problem is that, the session doesn't
> persist, each time I reload demo.sthml, a new session is created.
> Now get this... if I call miec.php and then demo.shtml, everything works.
> Why? My guess is, miec.php running solo is able to create the cookie with
> the session id, while when SSI included it can't, which explain the URLs.
> Obviously, URLs (example: demo.shtml?sID=3897348734) aren't helpful here,
> since it's a html file, and it can't parse the query string to send the
> variable to an SSI included php file.
> But why the cookie can't be created? Headers aren't the problem... if a
> session can be created and the session vars registered it's because the
> headers have not been sent, so why can't a cookie be created in this
> conditions.
> Does anyone has a clue??
> p.s: the problem is solved, I force the user to login in case of miec.php
> is SSI included, which works, since the session is created elsewhere
> (login.php).
> _____________________________
> . Christian Dechery
> . . Gaita-L Owner / Web Developer
> . .
> . .
> --
> PHP General Mailing List (
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

PHP General Mailing List (
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to