Aaron Bannert wrote:
It is painfully obvious that the requirement is not important enough to the PHP team (or the majority of PHP users) to cause them to hack their code to enable it to work effectively as an Apache 2 filter. I honestly don't blame them for the decision. If we care about our users, our development time should be spent on the things that have the most benefit to our users. Spending large amounts of time rewriting (and destabilizing) code used by 100% of the PHP user base for the sole purpose of providing a piddly capability that will only be used by an infintesmal fraction of PHP users is not a good investment. IMHO.On Thursday, February 6, 2003, at 10:15 AM, Bill Stoddard wrote:Also, I should point out that something as seemingly simple as an SSI file that includes multiple php scripts needs the filter stack.
So is that a popular configuration in use with 1.3 today? If not, then I hold this up as a trophy illustrating my earlier assertion regarding overengineered 'solutions' to non existent problems.
It doesn't really matter if it's in use by 1.3 today. If it's in use in 1.3 today then what use would 2.0 be? I've seen numerous bug reports stating this simple case. That to me validates this as a use case. -aaron
On an aside... I bet if you let mod_php be a handler, you can still do some pretty interesting things with output filters like mod_include. PHP would own the file descriptor and could be told (via config) to insert the SSI filter. Subrequests would be generated for the PHP tags and they would be handled by the PHP handler. I don't see that this requirement dictates PHP being a filter.
Bill
