Why use output buffering in PHP?

Question

I have read quite a bit of material on Internet, where different authors suggest using output buffering. The funny thing is that most authors argument for its use because it allows to set HTTP response headers while also generating response output. Frankly, if for no other reason, I think that responsible web applications SHOULD NOT mix outputting headers and content, and web developers instead should look for the errors where headers are in fact attempted to be sent after output has been generated - it most likely indicates errors in script flow control logic. This is my first argument against PHP's ob_ output buffering API. Even if for that little convenience it gives - "mixing" headers with output - that is not a good enough reason to use it, unless one needs to hack up scripts fast, which is not my current task at all.

Are there other, more important advantages to output buffering?

Also, I think most people meeting or dealing with the output buffering API do not think about the fact that even without the explicit output buffering enabled, PHP in combination with the web-server it is plugged into, STILL does some internal buffering. It is easy to check - do an echo of some short string, sleep for say 10 seconds, and do another echo. Request your script with a browser and watch as the blank page pauses for 10 seconds, and then both lines are shown at the same time. Before some say that it is a rendering artefact, not traffic, tracing the actual traffic between the client and the server shows that the server has generated the 'Content-Length' header with an appropriate value for the entire output - suggesting that the output was not sent progressively with each 'echo' call, but accumulated in some buffer and then sent on script termination. This is one of my gripes with explicit output buffering - why do we need two different output buffer implementations on top of one another? May it be because the internal (inaccessible) PHP/Web-server output buffering is subject to conditions a PHP developer cannot control, and is thus not really usable?

In any case, I for one, start to think one should avoid explicit output buffering (the series of ob_ functions) and rely on the implicit one, assisting it with the good flush function, when necessary. Maybe if there was some guarantee that a web server one uses actually sends output to the client on each echo/print call, then it would be useful to set up explicit buffering - after all one does not want to send response to the client with some 100 byte chunks. But the alternative with two buffers seems like a somewhat useless layer of abstraction.

Opinions are very welcome...

Answer 1

We used to use it back in the day for pages with enormously long tables filled with data from a database. You'd flush the buffer every x rows so the user knew the page was actually working. Then someone heard about usability and pages like that got paging and search.

Answer 2

i use output buffering for one reason ... it allows me to send a "location" header after i've begun processing the request.

Answer 3

It's useful if you're trying to display a progress bar during a page that takes some time to process. Since PHP code isn't multi-threaded, you can't do this if the processing is hung up doing 1 function.

Answer 4

Output buffering is critical on IIS, which does no internal buffering of its own. With output buffering turned off, PHP scripts appear to run a lot slower than they do on Apache. Turn it on and they run many times faster.

Answer 5

If you want to output a report to the screen but also send it through email, output buffering lets you not have to repeat the processing to output your report twice.

Answer 6

Ok, here is the real reason : the output is not started until everything is done. Imagine an app which open an SQL connection and don't close it before starting the output. What happen is your script get a connection, start outputting, wait for the client to get all it needs then, at the end, close the connection. Woot, a 2s connection where a 0.3s one would be enough.

Now, if you buffer, your script connect, put everything in a buffer, disconnect automatically at the end, then start sending your generated content to the client.

Answer 7

I use output buffering in order to avoid generating HTML by string concatenation, when I need to know the result of a render operation to create some output before I use the rendering.

Answer 8

The most obvious use cases are:

1. An output filter (eg ob_gzhandler or any number of filters you could devise on your own); I have done this with APIs that only support output (rather than return values) where I wanted to do subsequent parsing with a library like phpQuery.
2. Maintenance (rather than rewriting) of code written with all the problems you discuss; this includes things like sending headers after output began (credit Don Dickinson) or suppression of certain output that has already been generated.
3. Staggered output (credit here to Tom and Langdon); note that your tests may have failed because it conflicts with PHP/Apache's default internal buffer, but it is possible to do, it simply requires a certain amount to be flushed before PHP will send anything—PHP will still keep the connection open though.