https://issues.apache.org/bugzilla/show_bug.cgi?id=49328
--- Comment #3 from Alex Docauer <[email protected]> 2010-05-23 12:22:00 EDT --- (In reply to comment #2) > I don't think that your patch is correct. What about filters that expect their > init function to be called a second time? The following patch should fix that. > Could you please give it a try? I guess the question is whether filter_init_func _should_ be called more than once. It's description in util_filter.h is: /** The function to call before the handlers are invoked. Notice * that this function is called only for filters participating in * the http protocol. Filters for other protocols are to be * initialized by the protocols themselves. */ I read "before the handlers are invoked" to mean that I should never expect the filter_init_func to be called after the handler has been invoked. I think the best fix to this problem would be to make it so that Apache never calls filter_init_func more than once. However, that might require a change to the request_rec, and thus can only be incorporated into 2.3 or later. So, I would argue: 1) If it's decided that the behavior of calling filter_init_func a second time in a subrequest needs to be preserved for compatibility with existing 2.2 modules, then I would only apply your patch to the 2.2 branch while in trunk eliminating multiple calls to filter_init_func instead. 2) Any filter that relies on it's context being preserved in a subrequest is already broken when used with mod_filter. After fixing mod_filter's context handling, failing to call filter_init_func a second time shouldn't introduce new negative behavior. 3) I can't think of a case where one might actually expect filter_init_func to be called twice. Modules in the wild today that use filter_init_func most likely break in subrequests. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
