# Bug 61272 - Thread: https://externals.io/message/64038 - Original archive: https://news-web.php.net/php.internals/64038 - Started by Casper Langemeijer on 2012-11-25T10:58:31+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #64038 — Casper Langemeijer — 2012-11-25T10:58:31+00:00 URL: https://externals.io/message/64038#64038 Hi all, Somewhere in May this year I discovered that our software would not run on PHP 5.4 because of changed behaviour of `ob_start()`. I discovered a bugreport that was marked 'Not a bug', but valuable info was already added to it. I contacted Michael Wallner (mike) directly because he marked the bug 'not a bug'. No response. I decided that this bug was worth my time and invested a few hours into it. I have found that the test that tested it was broken too. I wrote a patch for the bug and the test and added this onto the bug report on June 8th. June 18th I re-opened the bugreport. I just got my php.net account. I thought re-opening the bug would mean it would get noticed by someone. Since then the bugreport gathered some me-too's and one thanks-for-the-patch. (At least my work has made one other person happy so far.) Two weeks ago I emailed Michael Wallner again. No response. I noticed Xinchen Hui (laruence) assigned the bug to mike two days ago. Based on my experiences so far, I don't think he will look into this issue though. Mike, please note that I do not blame you. I understand that free time is very sparse and valuable and for most of us doing any work on an open source project is done in free time. Can someone please look into this? I've written all I know in https://bugs.php.net/bug.php?id=61272 but I'm available to discuss the patch by email or in #php.pecl Greetings, Casper --- ## #64042 — Michael Wallner — 2012-11-26T09:19:20+00:00 URL: https://externals.io/message/64038#64042 · In reply to: #64038 > Hi all, > > Somewhere in May this year I discovered that our software would not run on > PHP 5.4 because of changed behaviour of `ob_start()`. I discovered a bugreport > that was marked 'Not a bug', but valuable info was already added to it. I > contacted Michael Wallner (mike) directly because he marked the bug 'not a > bug'. No response. 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. 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. No offense, no excuse, just a try to figure out what happened... -- Regards, Mike --- ## #64052 — Casper Langemeijer — 2012-11-26T14:46:04+00:00 URL: https://externals.io/message/64038#64052 · In reply to: #64042 > 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 --- ## #64062 — Michael Wallner — 2012-11-27T09:11:10+00:00 URL: https://externals.io/message/64038#64062 · In reply to: #64052 > 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) Which emphasizes the fact, that implementation and documentation differed quite a bit. The ob_clean note was obviously added in 2008 [1] [2], when the new output code was sleeping in the PHP6 branch. > > 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? I guess I got your argument now :) I'll have a look. Thanks for spending your time to make PHP better. [1] http://svn.php.net/viewvc/phpdoc/en/trunk/reference/outcontrol/functions/ob-start.xml?r1=246628&r2=268496 [2] https://bugs.php.net/bug.php?id=44150 -- Regards, Mike --- ## #64093 — Yasuo Ohgaki — 2012-11-29T07:00:21+00:00 URL: https://externals.io/message/64038#64093 · In reply to: #64038 Hi, Slightly related topic. I recently looked into new output code in PHP 5.4. It's MUCH nicer than older code. Good job! However, new code encapsulate output globals. (I mean internally) It would be nice for my extension if output globals are exposed. Exposing output global is not mandatory, though. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #64097 — Michael Wallner — 2012-11-29T09:30:13+00:00 URL: https://externals.io/message/64038#64097 · In reply to: #64093 > 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 --- ## #64172 — Yasuo Ohgaki — 2012-12-06T08:32:33+00:00 URL: https://externals.io/message/64038#64172 · In reply to: #64097 2012/11/29 Michael Wallner : > > > […] > > This was changed intentionally, why would you need OG what the API > does not provide? > > > […] Encapsulation is great for ordinary use, but I have extension that records PHP internal activities. It also records and override some contents of output global. I haven't thought what API would be needed, I'll look into current code later and what API is needed. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net