"Headers already sent" Bug

[b03tz]

Als ik inlog (de onderste "redirect(startpage)" even uitzet) krijg ik de bug:

PHP:

source niet meer nodig

En dit is de inc.functions.php:

PHP:

source niet meer nodig

Ik snap er niets van, heb al gezocht op internet en las dat er geen text geoutput mag worden voor de setcookie's ofzo?

Ik kom er niet uit...misschien zie 'k iets over het hoofd ?

[ Voor 93% gewijzigd door b03tz op 07-03-2007 10:48 ]

[Gonadan]

Een EOLN (enter) na de PHP afsluiten tag (?>) in een van je includes misschien?
Dat is 9 van de 10 keer het probleem.

output started at /home/www/vitix0r.awardspace.co.uk/controlpanel/includes/inc.functions.php:266

Tip: gebruik de volgende keer de
[code]je code[/] tags. Dan is je code een stuk leesbaarder.

[ Voor 50% gewijzigd door Gonadan op 07-03-2007 10:34 ]

[BtM909]

Zet je code eens tussen [code=php][/] tags om het leesbaarder te maken. En heb je Programming FAQ - Algemeen#debug al gelezen?

[b03tz]

Gonadan schreef op woensdag 07 maart 2007 @ 10:31:
Een EOLN (enter) na de PHP afsluiten tag (?>) in een van je includes misschien?
Dat is 9 van de 10 keer het probleem.


[...]


Tip: gebruik de volgende keer de
[code]je code[/] tags. Dan is je code een stuk leesbaarder.

Omg, een spatie na een ?>

Ehm..."dobbelyoe tee ef" maar super bedankt!

[Gonadan]

b03tz schreef op woensdag 07 maart 2007 @ 10:40:
[...]


Omg, een spatie na een ?>

Ehm..."dobbelyoe tee ef" maar super bedankt!

Hehe, je bent niet de eerste.
Maar zoiets overkomt je (hoogstwaarschijnlijk) maar een keer.

[b03tz]

Gonadan schreef op woensdag 07 maart 2007 @ 10:42:
[...]

Hehe, je bent niet de eerste.
Maar zoiets overkomt je (hoogstwaarschijnlijk) maar een keer.

Idd

Thanks alot man!!

[MueR]

Je zou kunnen proberen om output buffering te gebruiken. Dan voorkom je deze problemen grotendeels.

[Brakkie]

je kan de php sluit tag ook weg laten. Die is namelijk niet verplicht. Dan weet je zeker dat je na je script niet onbedoeld output naar de browser stuurt.

http://nl2.php.net/langua...ax.instruction-separation

Note: The closing tag of a PHP block at the end of a file is optional, and in some cases omitting it is helpful when using include() or require(), so unwanted whitespace will not occur at the end of files, and you will still be able to add headers to the response later. It is also handy if you use output buffering, and would not like to see added unwanted whitespace at the end of the parts generated by the included files.

[ Voor 62% gewijzigd door Brakkie op 07-03-2007 12:07 ]

[Blackbird-ce]

Brakkie schreef op woensdag 07 maart 2007 @ 12:06:
je kan de php sluit tag ook weg laten. Die is namelijk niet verplicht. Dan weet je zeker dat je na je script niet onbedoeld output naar de browser stuurt.

http://nl2.php.net/langua...ax.instruction-separation


[...]

moet je wel héééél zeker weten dat niemand direct je include-file kan benaderen. Is wat rot als je database-connectie gegevens zo worden uitgelezen

verkeerd begrepen/gelezen... enkel de sluit-tag weg laten haalt de file wel door de parser natuurlijk

[ Voor 10% gewijzigd door Blackbird-ce op 07-03-2007 12:55 . Reden: leeeeeezen Blackbird, lezen. ]

[b03tz]

Brakkie schreef op woensdag 07 maart 2007 @ 12:06:
je kan de php sluit tag ook weg laten. Die is namelijk niet verplicht. Dan weet je zeker dat je na je script niet onbedoeld output naar de browser stuurt.

http://nl2.php.net/langua...ax.instruction-separation


[...]

Hey thanks!

Goede tip!!

[FragFrog]

MueR schreef op woensdag 07 maart 2007 @ 11:36:
Je zou kunnen proberen om output buffering te gebruiken. Dan voorkom je deze problemen grotendeels.

In mijn (niet altijd even ) nedere opinie is output buffering om dit soort problemen op te lossen een zwak excuus voor goed coden. Daarnaast werkt het ook nog eens vertragend.

Al helemaal aangezien de error gewoon duidelijk aangeeft waar de output zit

Extra tip: er zijn goede edittors die netjes zelf whitespace aan het einde van je file kunnen weghalen zoals mijn persoonlijke favoriet UltraEdit.

[ReverendBizarre]

Lijk mij onzin. Ten eerste zie ik niet wat per ongeluk een regel whitespace ergens achterlaten met "goed coden" te maken heeft, ten tweede zijn output buffers totaal niet vertragend. En ik vind het zelf een mooiere oplossing dan de PHP close tag weglaten (maar dat is persoonlijk).

In mijn huidige project heb ik een ob_start() en ob_clean() om mijn config file gezet waarbinnen allerlei dingen geinclude worden (waaronder meerdere third party libs die op hun beurt ook weer van alles includen). Op die manier weet ik zeker dat geen van die bestanden op de een of andere manier output genereert die de boel in de war schopt. Werkt prima, en is echt niet langzamer.

[Brakkie]

FragFrog schreef op woensdag 07 maart 2007 @ 15:58:
[...]

In mijn (niet altijd even ) nedere opinie is output buffering om dit soort problemen op te lossen een zwak excuus voor goed coden. Daarnaast werkt het ook nog eens vertragend.

Volgens mij maakt output buffering je code juist sneller omdat alle output in 1 keer verstuurd wordt in plaats van in allemaal kleine stukjes. Het verzenden in kleine stukjes veroorzaakt netwerk overhead.

[ Voor 6% gewijzigd door Brakkie op 07-03-2007 17:16 ]

[FragFrog]

Brakkie schreef op woensdag 07 maart 2007 @ 17:11:
Volgens mij maakt output buffering je code juist sneller omdat alle output in 1 keer verstuurd wordt in plaats van in allemaal kleine stukjes. Het verzenden in kleine stukjes veroorzaakt netwerk overhead.

Het werkt vertragend doordat eerst je hele script klaar moet zijn voordat het verzenden begint en je browser er iets mee kan. Zeker bij wat grotere scripts kan dit zo een seconde of wat extra kosten.

Daarnaast is het niets meer dan extra code gebruiken om je eigen slordigheid op te vangen. Dat je het gebruikt om zeker van te zijn dat externe libraries geen whitespace outputten kan ik me voorstellen, maar als je kennelijk zulke slordig geschreven libraries include vraag ik me af of je niet beter zelf die functionaliteit kan schrijven of van een betere source halen. Ik gebruik zelf geregeld PEAR libraries en heb nog nooit output buffering daarvoor nodig gehad.

[Gonadan]

Eensch met ^^

En je browser kan dan ook pas beginnen met externe bestanden (plaatjes e.d.) downloaden als je script helemaal klaar is.
Dat vertraagt ook behoorlijk.
Ik gebruik buffering alleen bij 3rd party scripts die output genereren.

[Brakkie]

Als je aanneemt dat het maximaal 0,1 seconde duurt om een pagina aan de serverkant te genereren dan is het voordeel om output direct naar de client te versturen te verwaarlozen. (Deze thread doet er bijv. 0,1 sec over om gegenereerd te worden)

Onderstaand scriptje doet er bij mij met output buffering uit bijna 2x zo lang over om gegenereerd te worden dan met output buffering aan.

PHP:

$mtime = microtime(); 
$mtime = explode(' ', $mtime); 
$mtime = $mtime[1] + $mtime[0]; 
$starttime = $mtime; 
######################################

$dobuffer = false;

if($dobuffer) {
    ob_start();
}

for($i = 0; $i <= 100000; $i++) {
    echo "Dit is output die naar de browser gaat.<br>";
}

if($dobuffer) {
    $output = ob_get_clean();
    echo $output;
}

##########################################################
$mtime = microtime(); 
$mtime = explode(" ", $mtime);
$mtime = $mtime[1] + $mtime[0]; 
$endtime = $mtime; 
$totaltime = ($endtime - $starttime); 
echo 'This page was created in ' .$totaltime. ' seconds.';

[Gonadan]

Brakkie schreef op donderdag 08 maart 2007 @ 15:19:
Als je aanneemt dat het maximaal 0,1 seconde duurt om een pagina aan de serverkant te genereren dan is het voordeel om output direct naar de client te versturen te verwaarlozen. (Deze thread doet er bijv. 0,1 sec over om gegenereerd te worden)

Onderstaand scriptje doet er bij mij met output buffering uit bijna 2x zo lang over om gegenereerd te worden dan met output buffering aan.

Wat is dan sowieso het voordeel? Je zal dan echt geen verschil merken.
Het renderen van de pagina duur sowieso langer dan 0.1s.
Dus in mijn ogen haal je hier je eigen standpunt onderuit.

[Brakkie]

Een script dat lichter is voor de server vind ik anders een behoorlijk voordeel. Dat weegt naar mijn idee zwaarder dan content 0,1 seconde eerder naar de client sturen.

[Gonadan]

Brakkie schreef op donderdag 08 maart 2007 @ 15:26:
Een script dat lichter is voor de server vind ik anders een behoorlijk voordeel. Dat weegt naar mijn idee zwaarder dan content 0,1 seconde eerder naar de client sturen.

Het wordt voor je server niets lichter hoor.
Die moet nog steeds dezelfde taken uitvoeren. Alleen spaart hij de output even op.
Het zal hooguit voor je verbinding makkelijker zijn.

[Brakkie]

Heb altijd gedacht dat executie tijd wel het een en ander zegt over de zwaarte van een script en het testje spreekt wat dat betreft in het voordeel van OB.

(ik denk overigens niet de wijsheid in pacht te hebben wat dit betreft maar ga gewoon af op m'n testje)

[ Voor 25% gewijzigd door Brakkie op 08-03-2007 16:10 ]

[FragFrog]

Brakkie schreef op donderdag 08 maart 2007 @ 15:26:
Een script dat lichter is voor de server vind ik anders een behoorlijk voordeel. Dat weegt naar mijn idee zwaarder dan content 0,1 seconde eerder naar de client sturen.

Je script wordt er eerder zwaarder door dan lichter, je server moet immers -meer- doen. Kost meer geheugen, meer CPU kracht, meer tijd. Staat ook gewoon in de handleiding, je script slaat wat dat betrefd nergens op - de tijd die jij berekent is de executie tijd, echter zonder output buffering is dat NIET hetzelfde als de tijd die nodig is voor er iets gebeurt in je browser. Ga maar na, doe een zware berekening 10.000.000 keer, in het ene geval begin je direct met outputten en in het andere geval spaar je het op, in het eerste geval zul je dan direct output zien in het andere geval moet je eerst 30 seconden wachten. Natuurlijk duurt het uitvoeren van het script langer als'ie tussendoor op de client moet wachten, maar dat zorgt er niet voor dat het intensiever is, alleen dat je CPU belasting minder piekt!

Natuurlijk, niet in hoeveelheden die jij gaat missen, maar je zal maar een zware website als t.net maken ooit en continu dat soort dingen fout doen, dat ga je voelen.

Overigens betwijfel ik of het uberhaupt lichter is voor je verbinding, ethernet werkt immers al met packets, max MTU size is 1500 bytes, dus zo ongeveer elke site moet toch als meerdere packets de deur uit. Maar in plaats van dat je de upload uitsmeert over een langere tijd probeer je'm er nu in een keer door te jagen, zal alleen maar langer gaan duren voor je bezoekers. Wederom, niet veel, maar waarom -zou- je als het niet hoeft?

[ Voor 27% gewijzigd door FragFrog op 08-03-2007 16:18 ]

[Gonadan]

Brakkie schreef op donderdag 08 maart 2007 @ 16:10:
Heb altijd gedacht dat executie tijd wel het een en ander zegt over de zwaarte van een script en het testje spreekt wat dat betreft in het voordeel van OB.

(ik denk overigens niet de wijsheid in pacht te hebben wat dit betreft maar ga gewoon af op m'n testje)

Dat zou op zich nog wat uit kunnen maken.
Ik vraag me echter af wat er gebeurt als je erg veel output hebt.
Maak je dan nog winst, of wordt het dan te verwaarlozen?

Commandline PHP geeft:
0.043331861496 geen ob
0.0416879653931 ob

Ik kan dus niet echt zeggen dat het voor de server veel uit maakt.

[ Voor 11% gewijzigd door Gonadan op 08-03-2007 16:16 ]

[Janoz]

Executie tijd zegt in deze weinig over de zwaarte van het script. De tragere executietijd van de nonOB versie heeft denk ik eerder te maken met het wachten op IO. OB gebruiken is eerder zwaarder voor de server. Niet voor de processor, maar voor het geheugen. Er wordt immers voor elk request een extra buffer aangemaakt. Bij grote pagina's en veel hits kan dit toch best een merkbare aanslag op het beschikbare geheugen geven.

[Gonadan]

Nog 2 testen voor elk geeft:
0.042 0.43 met ob
0.025 0.025 zonder ob

Maar zoals Janoz al aangeeft maakt dat niet zo veel uit.

Mijn gevoel zegt me dat als je ob gebruikt je juist pieken in de belasting gaat genereren.
Zowel op het geheugen als op je verbinding.
Zonder ob wordt het veel geleidelijker afgehandeld.

[ Voor 63% gewijzigd door Gonadan op 08-03-2007 16:26 ]

[FragFrog]

Hmmzja, ik heb de relevante php.ini comment ook maar even opgezocht:

; Output buffering allows you to send header lines (including cookies) even
; after you send body content, at the price of slowing PHP's output layer a
; bit. You can enable output buffering during runtime by calling the output
; buffering functions. You can also enable output buffering for all files by
; setting this directive to On. If you wish to limit the size of the buffer
; to a certain size - you can use a maximum number of bytes instead of 'On', as
; a value for this directive (e.g., output_buffering=4096).
output_buffering = Off

Verder wat Gonadan en Janoz al zeiden natuurlijk

[Brakkie]

hehe dat is wel erg duidelijk. Ik ben overtuigd. Wel raar dat het bij mij lokaal wel sneller was

[ Voor 86% gewijzigd door Brakkie op 08-03-2007 16:48 ]

[Janoz]

Het hele OB gebeuren vind ik trouwens maar rotzooi. Het enige wat het doet is problemen die ontstaan door lelijke en ongestructureerde code te verdoezelen. Wanneer je je buisnesslogic en je view netjes gescheiden houdt zul je nooit in een situatie kunnen komen waarbij je halverwege het renderen je pagina weg moet gooien.

Ik heb nog nooit een php OB gebruikende pagina gezien waarbij geen (veel) nettere non OB oplossing mogelijk was.

[Gonadan]

Janoz schreef op donderdag 08 maart 2007 @ 16:43:
Het hele OB gebeuren vind ik trouwens maar rotzooi. Het enige wat het doet is problemen die ontstaan door lelijke en ongestructureerde code te verdoezelen. Wanneer je je buisnesslogic en je view netjes gescheiden houdt zul je nooit in een situatie kunnen komen waarbij je halverwege het renderen je pagina weg moet gooien.

Ik heb nog nooit een php OB gebruikende pagina gezien waarbij geen (veel) nettere non OB oplossing mogelijk was.

Dat ben ik op zich met je eens.
Maar ik heb bijvoorbeeld in de situatie gezeten dat ik third party epp/soap/xml scripts moest gebruiken die hoe dan ook output genereren.
Toen heb ik ob_start en ob_end_clean gebruikt om daar vanaf te raken.
Verder heb ik inderdaad nog nooit meegemaakt dat het nuttig was.

[Gomez12]

Btw output buffering kan je ook anders gebruiken. Je kunt het ook gebruiken om meer controle te krijgen over de output en wanneer iets verschijnt. Ik gebruik het bijvoorbeeld voor een voortgangsmeter, en zonder ob krijg ik een schokkerig effect ( zo af en toe komt er 1 blokje bij, zo af en toe 4 blokjes in 1x ) met ob zeg ik gewoon na elk blokje dat hij moet flushen

[FragFrog]

Janoz schreef op donderdag 08 maart 2007 @ 16:43:
ik heb nog nooit een php OB gebruikende pagina gezien waarbij geen (veel) nettere non OB oplossing mogelijk was.

Ik eenmaal met een AJAX library (sAJAX) die hardcoded echo's gebruikte in plaats van returns. OB gebruikt om z'n output toch in een variabele te kunnen donderen om aan Smarty door te geven. Andere optie was logic en view mengen, maar daar had ik nog minder zin in.

Alhoewel, als je doorredeneert was er natuurlijk ook nog de optie die hele ajax library weg te bonjouren en wat beters te pakken.. There you go..