Bekijk Volledige Versie : [php]"Cannot add header information" met cookies
Beste niwss,
Vandaag voor het eerst geprobeerd gebruik te maken van cookie's en of
sessie's.
Dit was echter geen succes, als ik cookie's wil gaan gebruiken, krijg ik de
volgende foutmelding:
Warning: Cannot add header information - headers already sent by (output
started at /home/school/public_html/login.php:2) in
/home/school/public_html/login.php on line 32
Echter, in de manual kan _ik_ niet vinden wat ik verkeerd doe.
Ook als ik sessie's wil gaan gebruiken krijg ik een foutmelding.
Zou iemand mij kunnen vertellen wat er verkeerd is in mijn script, en/of hoe
ik sessie's kan gebruiken? (cookies worden niet altijd geaccepteerd).
Hieronder de door mij gebruikte php script:
<?php
$nick = $_POST["nick"];
$password = $_POST["pass"];
$user_select=mysql_db_query("$sql_database","select * from users where
nick='$nick'");
$user_row=mysql_fetch_array($user_select);
$pass=base64_decode($user_row[pass]);
if($pass==$password){
echo "Welkom ".$user_row["voornaam"]." ".$user_row["tussenv"]."
".$user_row["achternaam"]."\n<br>";
echo "<br>Deze pagina maakt gebruik van cookies. zorg ervoor dat u Cookies
accepteerd!";
Setcookie("login",$user_row["nick"], null);
}else{
echo "het is niet gelukt om in te loggen!";
}
?>
ziet iemand hierin een fout? of kan iemand mij in duidelijk nederlands
uitleggen hoe ik sessie's || cookies kan gebruiken?
alvast bedankt,
Sven Goosen
Jan Ehrhardt
07/10/03, 20:15
Sven in nl.internet.www.server-side (Tue, 7 Oct 2003 19:50:45 +0200):
>Vandaag voor het eerst geprobeerd gebruik te maken van cookie's en of
>sessie's.
>Dit was echter geen succes, als ik cookie's wil gaan gebruiken, krijg ik de
>volgende foutmelding:
>
>Warning: Cannot add header information - headers already sent by (output
>started at /home/school/public_html/login.php:2) in
>/home/school/public_html/login.php on line 32
set_cookie is een 'header' opdracht. Die moet dus geplaatst worden
voordat je tekst naar de browser stuurt.
Jan
--
Look, Ma. No tables - http://www.steenbergen-stichting.nl/enbio.html
Daniel Tryba
07/10/03, 20:15
Sven <sven@enygma-demon.nl> wrote:
> volgende foutmelding:
>
> Warning: Cannot add header information - headers already sent by (output
> started at /home/school/public_html/login.php:2) in
> /home/school/public_html/login.php on line 32
>
> Echter, in de manual kan _ik_ niet vinden wat ik verkeerd doe.
Als je de foutmelding goed leest zie je staan:
Kan op regel 32 geen header sturen, immers headers zijn reeds verstuurt
op regel 2.
Het probleem start dus op regel 2 (vaag indien '<?php' op de eerste
regel staat, want dan zou het namelijk regel 11 zijn).
> Ook als ik sessie's wil gaan gebruiken krijg ik een foutmelding.
Ook session_start() probeert een cookie te zetten.
> Zou iemand mij kunnen vertellen wat er verkeerd is in mijn script,
Een http response "bestaat uit" 2 delen, de headers en de body, deze
zijn gescheiden door een lege regel. Als je dus (body) output genereerd
moeten de headers al zijn verstuurd, alsnog headers sturen na body ouput
is dus onmogelijk. Je dient dus de flow van je script aan te passen (of
terug te grijpen of "hacks" als output buffering).
> en/of hoe ik sessie's kan gebruiken? (cookies worden niet altijd
> geaccepteerd).
Sessies zijn (tenzij je 'transparante sessies') ook gewoon cookies.
--
Daniel Tryba
Jan Ehrhardt wrote:
> Sven in nl.internet.www.server-side (Tue, 7 Oct 2003 19:50:45 +0200):
>
>> Vandaag voor het eerst geprobeerd gebruik te maken van cookie's en of
>> sessie's.
>> Dit was echter geen succes, als ik cookie's wil gaan gebruiken,
>> krijg ik de volgende foutmelding:
>>
>> Warning: Cannot add header information - headers already sent by
>> (output started at /home/school/public_html/login.php:2) in
>> /home/school/public_html/login.php on line 32
>
> set_cookie is een 'header' opdracht. Die moet dus geplaatst worden
> voordat je tekst naar de browser stuurt.
is dit ook het geval bij session_start() ?
Sven
Arjen Haayman
07/10/03, 21:15
Jan Ehrhardt wrote:
> set_cookie is een 'header' opdracht. Die moet dus geplaatst worden
> voordat je tekst naar de browser stuurt.
Ik heb geen php ervaring, maar ik ken dit probleem wel met ASP. Bij ASP
kun je wel HTTP-headers aanpassen terwijl er al <HTML> uitvoer is
geweest *MITS* de uitvoer gebufferd is. Dan worden de HTTP-headers
alsnog vooraan geplaatst. Als dit bij php niet zo werkt, kun je deze
opmerking als niet verzonden beschouwen ;-)
--
Arjen Haayman
-- cogito ergo bicyclo --
Sven wrote:
> of kan iemand mij in duidelijk nederlands
> uitleggen hoe ik sessie's || cookies kan gebruiken?
Zie ook http://www.free2code.net/tutorials/programming/php/4/sessions.php
(geen antwoord op wat er fout is maar dat heb je elders al gehad.)
--
Inca
NEE - Vrijheid is niet te koop
JA - Wel voor olie
http://www.poldermodelstickers.nl/
Maarten Wierda
07/10/03, 21:15
Arjen Haayman wrote:
>> set_cookie is een 'header' opdracht. Die moet dus geplaatst worden
>> voordat je tekst naar de browser stuurt.
>
> Ik heb geen php ervaring, maar ik ken dit probleem wel met ASP. Bij ASP
> kun je wel HTTP-headers aanpassen terwijl er al <HTML> uitvoer is
> geweest *MITS* de uitvoer gebufferd is. Dan worden de HTTP-headers
> alsnog vooraan geplaatst. Als dit bij php niet zo werkt, kun je deze
> opmerking als niet verzonden beschouwen ;-)
Dat kan inderdaad ook in PHP.
Maarre, klopt het dat als je op deze manier te werk gaat, dat je ergens
iets op een "verkeerde" manier hebt afgehandeld? Of denk ik verkeerd als
ik veronderstel dat de buffer functie voor dit soort foutmeldingen een
"ranzige" oplossing is?
Ik ben (nu nog tenminste) nl. van mening dat als je code goed is
opgebouwd dat je dit soort foutmeldingen helemaal niet hoeft te krijgen.
Graag jullie mening hierover.
--
Cheers, Maarten Wierda
Q: What do you call someone who hangs around with musicians?
A: A drummer.
Maarten Wierda wrote:
[output buffering gebruiken?]
> Ik ben (nu nog tenminste) nl. van mening dat als je code goed is
> opgebouwd dat je dit soort foutmeldingen helemaal niet hoeft te
> krijgen.
>
> Graag jullie mening hierover.
Ik heb geen voorbeelden voor of tegen, maar ik denk dat je in de meeste
gevallen wel gelijk hebt.
Er zijn echter wel situaties waarin het echt niet mogelijk is om de dingen
in de 'juiste' volgorde te doen, en waarbij de enige oplossing toch een vorm
van buffering is. Het maakt volgens mij dan niet uit of je dat doet via
eigengemaakte variabelen, of via output-buffering. Die gevallen komen echter
niet zo heel vaak voor. (Bij mij tenminste)
--
Inca
JA - Wel liberalisatie stroomnet
NEE - Geen stroom
http://www.poldermodelstickers.nl/
Maarten Wierda
07/10/03, 21:30
Inca wrote:
[output buffering gebruiken?]
>>Ik ben (nu nog tenminste) nl. van mening dat als je code goed is
>>opgebouwd dat je dit soort foutmeldingen helemaal niet hoeft te
>>krijgen.
>>
>>Graag jullie mening hierover.
>
> Ik heb geen voorbeelden voor of tegen, maar ik denk dat je in de meeste
> gevallen wel gelijk hebt.
Yeah!
> Er zijn echter wel situaties waarin het echt niet mogelijk is om de dingen
> in de 'juiste' volgorde te doen, en waarbij de enige oplossing toch een vorm
> van buffering is.
<snip>
Ik bedenk me nu ook pas dat ik de laatste tijd veel gebruik maak van
Smarty, een template-systeem wordt door PHP wordt ondersteund. Op deze
manier handel ik alles in e1n bestand af en wordt de HTML-code middels
template-bestanden getoond. Het is je vast wel enigszins bekend ;-)
Maar goed, indien HTML-code en PHP-code door elkaar gebruikt wordt,
wordt het al een stuk lastiger om afhandelingen op de juiste manier te
verrichten, zoals jij ook beschrijft.
Ok, helder nu. Ik had zelf toch wel iets dieper mogen nadenken hierover ;-)
--
Cheers, Maarten Wierda
cp: Team Dresch - Fagetarian And Dyke
Q: What do you call someone who hangs around with musicians?
A: A drummer.
Maarten Wierda wrote:
> Arjen Haayman wrote:
>
>>> set_cookie is een 'header' opdracht. Die moet dus geplaatst worden
>>> voordat je tekst naar de browser stuurt.
>>
>> Ik heb geen php ervaring, maar ik ken dit probleem wel met ASP. Bij ASP
>> kun je wel HTTP-headers aanpassen terwijl er al <HTML> uitvoer is
>> geweest *MITS* de uitvoer gebufferd is. Dan worden de HTTP-headers
>> alsnog vooraan geplaatst. Als dit bij php niet zo werkt, kun je deze
>> opmerking als niet verzonden beschouwen ;-)
>
> Dat kan inderdaad ook in PHP.
>
> Maarre, klopt het dat als je op deze manier te werk gaat, dat je ergens
> iets op een "verkeerde" manier hebt afgehandeld? Of denk ik verkeerd als
> ik veronderstel dat de buffer functie voor dit soort foutmeldingen een
> "ranzige" oplossing is?
Ja, je moet het gewoon anders zien. Met asp bouw je een pagina, en als
ie af is dan stuur je m naar de browser, terwijl je met php een voor een
afdrukt wat je naar de browser stuurt. Het is imho zeker geen vieze
oplossing, ik vind t eigenlijk veel logischer. Maar asp is ook wat meer
sessiegericht nog dan php volgens mij (maar daar kan ik me vergissen,
ben niet zo superbekend met php namelijk)
Mark
Daniel Tryba
11/10/03, 14:45
Marcus <mark@ijbema.xs4all.nl> wrote:
>> Maarre, klopt het dat als je op deze manier te werk gaat, dat je ergens
>> iets op een "verkeerde" manier hebt afgehandeld? Of denk ik verkeerd als
>> ik veronderstel dat de buffer functie voor dit soort foutmeldingen een
>> "ranzige" oplossing is?
>
> Ja, je moet het gewoon anders zien. Met asp bouw je een pagina, en als
> ie af is dan stuur je m naar de browser, terwijl je met php een voor een
> afdrukt wat je naar de browser stuurt.
Hoe kom je daar bij? De laatste IIS (4) waar ik mee gewerkt heb heeft
default output buffering uit staan en gedraagt zicht precies zoals PHP
zich gedraagt
> Het is imho zeker geen vieze oplossing, ik vind t eigenlijk veel
> logischer.
Daar ben ik het dus niet mee eens. SSS zijn binnen een aanroep statisch,
je kunt dus de benodigde externe gegevens ophalen en de flow bepalen
voordat je ook maar 1 byte aan output stuurt, denk aan MCV.
BTW wat als een request lang duurt? Dan kan je de output niet gaan
bufferen aangezien browsers over het algemeen een max timeout hebben op
het wachten op de reply.
BTW ik maak in enkele projecten dankbaar gebruik van outbuffer handling
om op die manier de output ge-gzip-ed te kunnen sturen naar clients.
> Maar asp is ook wat meer sessiegericht nog dan php volgens mij (maar
> daar kan ik me vergissen, ben niet zo superbekend met php namelijk)
??? Wat is sessiegericht? De enige verschillen die ik ken tussen ASP en
PHP is dat PHP een taal is en ASP een applicatie framework, dat
framework biedt standaard een aantal triggers bij het aanmaken van
sessies (iets dat je in PHP kan mbv een custom sessie handler).
--
Daniel Tryba
Daniel Tryba wrote:
> Marcus <mark@ijbema.xs4all.nl> wrote:
>>> Maarre, klopt het dat als je op deze manier te werk gaat, dat je ergens
>>> iets op een "verkeerde" manier hebt afgehandeld? Of denk ik verkeerd als
>>> ik veronderstel dat de buffer functie voor dit soort foutmeldingen een
>>> "ranzige" oplossing is?
>>
>> Ja, je moet het gewoon anders zien. Met asp bouw je een pagina, en als
>> ie af is dan stuur je m naar de browser, terwijl je met php een voor een
>> afdrukt wat je naar de browser stuurt.
>
> Hoe kom je daar bij? De laatste IIS (4) waar ik mee gewerkt heb heeft
> default output buffering uit staan en gedraagt zicht precies zoals PHP
> zich gedraagt
De IIS waarmee ik werk stond dat dus aan (niet door mij geconfigd of zo
overigens)
>> Het is imho zeker geen vieze oplossing, ik vind t eigenlijk veel
>> logischer.
>
> Daar ben ik het dus niet mee eens. SSS zijn binnen een aanroep statisch,
> je kunt dus de benodigde externe gegevens ophalen en de flow bepalen
> voordat je ook maar 1 byte aan output stuurt, denk aan MCV.
Dat is nu ook juist wat je doet met die buffer.
> BTW wat als een request lang duurt? Dan kan je de output niet gaan
> bufferen aangezien browsers over het algemeen een max timeout hebben op
> het wachten op de reply.
Scripts die zo traag zijn zouden ook niet per request moeten mogen
draaien. Dan is er ergens een architectuurfoutje gemaakt of zo.
>> Maar asp is ook wat meer sessiegericht nog dan php volgens mij (maar
>> daar kan ik me vergissen, ben niet zo superbekend met php namelijk)
>
> ??? Wat is sessiegericht? De enige verschillen die ik ken tussen ASP en
> PHP is dat PHP een taal is en ASP een applicatie framework, dat
> framework biedt standaard een aantal triggers bij het aanmaken van
> sessies (iets dat je in PHP kan mbv een custom sessie handler).
Dat er iets als een soort altijd aanwezige sessie is, dat is wat ik
ervan begrepen heb, maar nogmaals, ik ken asp niet zozeer (wordt op mijn
werk 'gedwongen' ermee te werken, en wil er verder eigenlijk zo weinig
mogelijk van afweten ;) )
Mark
Daniel Tryba
11/10/03, 18:00
Marcus <mark@ijbema.xs4all.nl> wrote:
>>> Het is imho zeker geen vieze oplossing, ik vind t eigenlijk veel
>>> logischer.
>>
>> Daar ben ik het dus niet mee eens. SSS zijn binnen een aanroep statisch,
>> je kunt dus de benodigde externe gegevens ophalen en de flow bepalen
>> voordat je ook maar 1 byte aan output stuurt, denk aan MCV.
>
> Dat is nu ook juist wat je doet met die buffer.
Hmmm, maar output buffering en MCV is echt heel iets anders. Met de
eerste (welke natuurlijk ook op pagina's geproduceerd met het MCV
concept kan toepassen) buffer je output, met de 2de "buffer" je data
voordat je met de output begint.
>> BTW wat als een request lang duurt? Dan kan je de output niet gaan
>> bufferen aangezien browsers over het algemeen een max timeout hebben op
>> het wachten op de reply.
>
> Scripts die zo traag zijn zouden ook niet per request moeten mogen
> draaien. Dan is er ergens een architectuurfoutje gemaakt of zo.
Ik heb het niet over een traag script, maar een request die een lange
tijd output levert, significant verschil. Het probleem is dat indien je
alles buffert de browser geen reply op z'n request krijgt en het
opgeeft.
>>> Maar asp is ook wat meer sessiegericht nog dan php volgens mij (maar
>>> daar kan ik me vergissen, ben niet zo superbekend met php namelijk)
>>
>> ??? Wat is sessiegericht? De enige verschillen die ik ken tussen ASP en
>> PHP is dat PHP een taal is en ASP een applicatie framework, dat
>> framework biedt standaard een aantal triggers bij het aanmaken van
>> sessies (iets dat je in PHP kan mbv een custom sessie handler).
>
> Dat er iets als een soort altijd aanwezige sessie is, dat is wat ik
> ervan begrepen heb,
Je bedoelt het Application object? Dat zou je kunnen zien als een sessie
voor alle gebruikers van de applicatie
> maar nogmaals, ik ken asp niet zozeer (wordt op mijn werk 'gedwongen'
> ermee te werken, en wil er verder eigenlijk zo weinig mogelijk van
> afweten ;) )
Eerst maak je een verglijking ASP<->PHP en zeg je dat je niet al te veel
van PHP weet, en nu blijkt dat je ASP ook niet geweldig beheerst :)
--
Daniel Tryba
Daniel Tryba wrote:
> Eerst maak je een verglijking ASP<->PHP en zeg je dat je niet al te veel
> van PHP weet, en nu blijkt dat je ASP ook niet geweldig beheerst :)
Ik kan me in beiden wel redden (bij asp in vbscript), maar ben van
beiden niet erg diepgaand op de hoogte, vnl omdat ik beide talen (andere
talen voor asp heb ik geen ervaring mee), niet echt fijn vindt
programmeren. Maar in ASP heb ik de beschikking over een of ander Sessie
object, met daarin bv of de gebruiker is ingelogd, maar dat zal
waarschijnlijk wel ergens in een includefile staan.
Mark
houdt t toch maar bij perl :)