How about the sessions? doesn't sessions also needs to send header data (before any other output)?
the sessions are registered normally.. At 17:07 12/11/01 -0800, Christopher William Wesley 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]