https://issues.apache.org/bugzilla/show_bug.cgi?id=17629
--- Comment #30 from Alex Docauer <[email protected]> 2010-04-25 23:51:43 EDT --- I believe I have identified the cause of this issue and have a resolution. mod_filter appears to be the only module that uses the filter_init_func field of the ap_filter_rec_t structure. This member is a pointer to function that is to be run right after the insert_filter hooks are run and right before the content handler is invoked. As most modules do their initialization at the time they are called to process data, this feature is largely unused. However, mod_filter chooses to do its initialization here so that it can correctly call the filter_init_func of each provider if it exists. mod_filter sets filter_init_func to be a pointer to its filter_init function. In filter_init, it first creates the context for the harness, before calling filter_init_func of each provider. The initial context for each provider and the ongoing context of the subsequently invoked provider are all stored in the harness context. The problem arises in that mod_filter intuitively assumes that filter_init will only ever be called once during the lifetime of the filter harness. However, when mod_include creates a subrequest, all of the filters from the main request get copied into the subrequest. Before the content handler is invoked in the subrequest, the filter_init_func of every filter in the subrequest gets called. This means that the filter_init_func of the filter harness gets called again, one addition time for each subrequest. The first thing that mod_filter does in filter_init is to assign the context pointer to freshly allocated memory. When called more than once, this essentially destroys the existing harness context and any provider contexts that it contains. In the case of mod_deflate, it loses any data waiting in the compression buffer. Furthermore, when mod_deflate is invoked again without a context, it assumes it is being called for the first time in that request. When it sees that Content-Encoding is already set to gzip, it removes itself from the filter chain, leaving the remaining output uncompressed. I don't know if it's considered correct or ideal operation that filter_init_func can be called more than once, but as it stands, mod_filter can't assume that it doesn't. I am attaching a small patch that will make filter_init first check for an existing harness context, simply returning if it finds one already exists. I tested this patch with 2.2.14. -- 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]
