Bug 61272

I'm sorry that the new output control layer causes you such headaches.
IIRC, 6 years back, when I implemented the new output control
functionality, I kindly asked the list, whether to rather implement
what's documented, or what the old code did, but I have yet been
unable to find according mails.
And now this code hits production for the first time I assume, if this
is the only issue I think you have done a fab job!
It pretty well may have been the case that the old code passed the
output buffer contents through the handler prior discarding, but as it had
not been documented (and I obviously failed to figure out a use case) I
apparently implemented the more efficient way it currently is.
Hmm.. I suppose It's up to me to make a strong (if possible watertight)
plea for the old way. I will try:

1. I don't think my patch impacts the efficiency of php_output_clean().
   It adds a single if with a binary compare. True: this causes output to
   get piped through the output handler, but the output handler callback
   function could be smart enough to back off when the
   PHP_OUTPUT_HANDLER_CLEAN bit is set in the second parameter of the callback.

2. Current behaviour is not according the documentation. ob_start()
   documentation states: " An optional output_callback function may be
   specified. This function takes a string as a parameter and should return
   a string. The function will be called when the output buffer is flushed
   (sent) or cleaned (with ob_flush(), ob_clean() or similar function)
   or when the output buffer is flushed to the browser at the end of the
   request. When output_callback is called, it will receive the contents of
   the output buffer as its parameter and is expected to return a new
   output buffer as a result, which will be sent to the browser."
   (*-emphasis mine)

Current behaviour differs:
On calling ob_end_clean() or ob_clean(), output_callback is called, but
without the contents of the output buffer as its parameter.

3. Implementing my patch will never break anything. The output will be
   passed to the callback, but anything returned by it will be discarded.

4. If you are not going to pass the contents of the output buffer on
   ob_end_clean() or ob_clean() to the callback function, Why would you
   call the callback anyway?

You may think this is a weird feature, this is how we use it: In
output_callback we assign the output we catch with output buffering to a
string variable, and we use that later on in the request to build our
output.

Greetings, Casper

I recently looked into new output code in PHP 5.4.
It's MUCH nicer than older code. Good job!

Appreciated!

However, new code encapsulate output globals. (I mean internally)
It would be nice for my extension if output globals are exposed.

This was changed intentionally, why would you need OG what the API
does not provide?

Exposing output global is not mandatory, though.

--
Regards,
Mike