But what about the session? It get's registered... doesn't sessions also 
need to send header information?
it gets registered... it just doesn't persist...

At 17:07 12/11/01 -0800, you wrote:
>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
> > . . http://www.webstyle.com.br
> > . . http://www.tanamesa.com.br
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > 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 (http://www.php.net/)
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


_____________________________
. Christian Dechery
. . Gaita-L Owner / Web Developer
. . http://www.webstyle.com.br
. . http://www.tanamesa.com.br


-- 
PHP General Mailing List (http://www.php.net/)
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