Zeev Suraski wrote:
I misread the post, I thought we were talking about ob_end_clean().
Yes, ob_clean() may cause this problem to happen, but again, the right
approach would be having an 'applicative' output buffer on top of the
gzip output buffer. We can look into letting output handlers denote
that ob_clean() is not allowed on them.
This would be in deed an option.
If you still consider a rather fundamental enhancement of the output control
code, please take a look at my initial try. It already /seems to work/ but
probably misses a few things. I must admit though, that I did not fully
understand the current implementation.
Considered issues:
Support of contexts for internal output handlers that had to maintain
it in a global variable, which caused those handlers being only usable
once; while often natural, like for the gz handler, still a limitation.
Conflict handlers, so that one doesn't need to incorporate that
code directly in output.c, but register them from within an extension etc.
Distinct ops, like FLUSH and CLEAN to signal the handler what's
going on; there should also be a possibility to change the abilities of
a handler in runtime, which is not implemented yet, eg. the gz handler
could remove the CLEANABLE and REMOVABLE flags when the first output
did pass through it.
Unfortunately I don't know which version of re2c Ilia used to generate
the url scanner, so a big part of the diff is pretty useless; note that
the patch is against current 5_1 CVS.
http://dev.iworks.at/PATCHES/ob.patch.txt.gz
http://dev.iworks.at/PATCHES/output.c.txt
http://dev.iworks.at/PATCHES/php_output.h.txt
Thanks a lot,
--
Michael - <mike(@)php.net> http://dev.iworks.at/ext-http/http-functions.html.gz
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
