2010-05-27 6 views
6

Vedo (non solo su questo sito) un sacco di domande da programmatori PHP inesperti sulle infami "intestazioni già inviate ... output avviato a" errore e molte persone suggeriscono di utilizzare il buffering ouput come soluzione.Caso di utilizzo per il buffering dell'output come soluzione corretta per "intestazioni già inviate"

Nella mia esperienza non ho mai trovato una situazione in cui quell'errore non fosse causato da un difetto nella logica del programma. Esistono casi in cui il buffering dell'output è in realtà la soluzione corretta?

risposta

4

Concordo con la tua dichiarazione iniziale. Generalmente, risolvere il problema "headers" con il buffering dell'output è una misura di stopgap.

La parte veramente triste/divertente di questa soluzione è: cosa succede quando si desidera generare qualcosa di grande, come un file che si sta nascondendo dietro un paywall? Di solito, le persone sostituiscono il problema degli "intestazioni" con i loro script che esauriscono la memoria.

Whoops.

0

per sistemi di template avrete bisogno ob_start ... guardare e Zend_View

tardi Edit ho frainteso la questione e ha fornito un caso in cui l'uso ob_start è una soluzione valida.

+0

si può elaborare? –

+0

È vero, i sistemi di template ne hanno bisogno. La domanda riguarda comunque le situazioni "Headers già inviate". – deceze

+1

solomongaby implica che alcuni sistemi di template utilizzano il buffering dell'output per eseguire il rendering dei frammenti del modello da unire in una fase successiva del rendering.Tuttavia, mentre questo è un uso valido del buffering dell'output, non è una spiegazione del perché il buffering potrebbe essere un modo valido per risolvere il problema delle "intestazioni" che è la domanda originale. – ivans

2

L'unica situazione che posso immaginare è un CMS o Weblog in cui i plugin può essere richiamato nel codice HTML, come

<h1>My images</h1> 
{plugin:show_images} 

questi plugin potrebbe essere necessario aggiungere i propri fogli di stile e altre cose che vanno in la sezione <head> della pagina. Usando il buffering, questo sarebbe possibile.

In pratica, tuttavia, ciò non è positivo per le prestazioni, si sente kludgy e non funziona quando il buffer di output è disattivato. Anche qui, è quindi meglio pre-processare i contenuti prima di mostrarli, e fare qualsiasi aggiunta di fogli di stile ecc. Prima che venga prodotto qualcosa.

+1

Penso che tu stia parlando di un altro problema. HTML è diverso dall'intestazione HTTP. –

+1

@ZZ Coder no, sto parlando di inserire il codice in un luogo che è "sopra" il luogo che stai elaborando al momento. Che questa sia una posizione diversa all'interno di '' o l'elemento '' non ha molta importanza. Il punto riguarda l'utilizzo del buffering per modificare l'output prima che venga inviato. –

+0

@Pekka 웃 Quale non è esattamente la domanda. – immibis

0

Si potrebbe voler inviare reindirizzamenti HTTP in ritardo nel flusso, ad esempio nei modelli o nella gestione delle eccezioni. (Naturalmente, un framework con gestione di eccezioni globale o di modelli richiederebbe comunque un buffer di output, quindi potresti dire che non è una soluzione specifica.)

0

Nella mia esperienza non ho mai trovato una situazione in cui quell'errore non è stato causato da un flusso nella logica del programma. Esistono casi in cui il buffering dell'output è in realtà la soluzione corretta?

avrei dovuto essere d'accordo con te, però:

1) Uno dei motivi che mi piace PHP è perché permette di scegliere come risolvere il problema

2) ci sono altri utilizza per output_buffering diverso dal fissare il messaggio "Intestazioni già inviate", ad es comprimendo uscita, catturando l'uscita di codice arbitrario, evitando la codifica Chunked ....

C.

Problemi correlati