Re: cvs: php-src(PHP_5_2) / NEWS /ext/filter filter.c /ext/filter/tests bug39763.phpt

On 8-Dec-06, at 2:05 PM, Stefan Esser wrote:

a) support daisy chaining

Can you not provide your own hooks and have them call the stock filter functions?

I (my extensions) have no problem with that. I just wonder why PHP got input filter hooks in one version and in a few versions later they are not useable anymore, because ext/filter grabs them.

Don't get me wrong its not a bad idea to have daisy chaining, its just that there was no need for it expressed before so it was never done.

b) does not register the variables itself but actually work as filters were supposed to do.

I think it makes the API simpler, but it would not be major change to make if there was a really good reason to do so.

The reason is simple: The filter extension abuses the input filtering hooks. The variables are no longer registered at one single place but several codepaths lead to different results. The bug you fixed with your commit is the best example: If ext/filter would not try to register the variables itself, this bug would never have happened.

There are a few reasons why it is doing it, foremost of which is the attempt to reduce the amount of memory utilized while registering variables. The last thing we want to do is allocate, re-allocate and so on every input parameter. I suspect there is a way to achieve a solution that would prevent duplication of data, which we still have right now with the RAW filter.

c) Support Cookies correctly...

Very simple: In some earlier version php_register_variable_ex was changed to handle cookies different from other variables: Cookies with the same name will get dropped after the first is registered. In ext filter the raw variables still have this behaviour but the filtered variables behave different...

I need to look into that, I recall adding checks for cookie hierarchy based on paths into "core" PHP, but I have not played with the equivalent filter code yet. Ilia Alshanetsky