Add a filter_init function to the filters so that a filter can execute

arbitrary code before the handlers are invoked.

This resolves an issue with incorrect 304s on If-Modified-Since mod_include
requests since ap_meets_conditions() is not aware that this is a dynamic
request and it is not possible to satisfy 304 for these requests (unless
xbithack full is on, of course).  When mod_include runs as a filter, it is
too late to set any flag since the handler is responsible for calling
ap_meets_conditions(), which it should do before generating any data.

If a module doesn't need to run such arbitrary code, it can just pass NULL
as the argument and all is well.

PR:	9673
Reviewed by:	Ryan Bloom and others

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95906 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/ssl_engine_io.c b/ssl_engine_io.c
index 47e76329c49ee57a9829c53c5f39d09d50bf077e..cdb6c965c6b172bc5f6b00d925bb0509fd3090ea 100644 (file)
--- a/ssl_engine_io.c
+++ b/ssl_engine_io.c
@@ -943,8 +943,8 @@ void ssl_io_filter_init(conn_rec *c, SSL *ssl)
 
 void ssl_io_filter_register(apr_pool_t *p)
 {
-    ap_register_input_filter  (ssl_io_filter, ssl_io_filter_Input,  AP_FTYPE_CONNECTION + 5);
-    ap_register_output_filter (ssl_io_filter, ssl_io_filter_Output, AP_FTYPE_CONNECTION + 5);
+    ap_register_input_filter  (ssl_io_filter, ssl_io_filter_Input,  NULL, AP_FTYPE_CONNECTION + 5);
+    ap_register_output_filter (ssl_io_filter, ssl_io_filter_Output, NULL, AP_FTYPE_CONNECTION + 5);
     return;
 }