On Fri, 7 Jun 2002, Justin Erenkrantz wrote: > In discussions about how to properly handle 304 (not modified), it > seems to me that we need a way for a filter to explicitly run some > code before the handler (and hence any data is generated) is > executed. > So, I propose adding another argument to the register functions - > typedef int (*ap_init_filter_func)(ap_filter_t *f); > ap_register_output_filter will look like: > AP_DECLARE(ap_filter_rec_t *) ap_register_output_filter(const char *name, > ap_out_filter_func filter_func, > ap_init_filter_func filter_init, > ap_filter_type ftype) > ap_register_input_filter will look like: > AP_DECLARE(ap_filter_rec_t *) ap_register_input_filter(const char *name, > ap_in_filter_func filter_func, > ap_init_filter_func filter_init, > ap_filter_type ftype);
+1. Seems like the best way to do it. My only question is: what about the AP_MODE_INIT flag on ap_get_brigade()? Couldn't that go away now in favor of the new ap_register_input_filter() parameter? It always seemed like a bit of a hack to me, and by shifting that burden over to ap_r_i_f(), we make the input and output filters behave more alike. For example, another way to solve this problem would have been to add a AP_MODE_INIT-style parameter to ap_pass_brigade() so the output filters could do what the input filters do, but that seems a bit hokey. The alternative is to get rid of AP_MODE_INIT and do it all through ap_register_*_filter. Or we could just have both, but I don't see what the point of that would be. Thoughts? --Cliff
