Looking over the code, impl as a hook seems more "isolated", rather than the current impl which is intrusive (which is part of what we're trying to avoid, aren't we?)
On Jan 24, 2012, at 4:08 PM, Stefan Fritsch wrote: > On Tue, 24 Jan 2012, Joe Orton wrote: > >> On Mon, Jan 23, 2012 at 09:39:38PM +0100, Stefan Fritsch wrote: >>> This patch allows us to later add members to core_ctx_t without >>> breaking binary compatibility to mod_ftp. Without such a patch, the >>> size of core_ctx_t is part of the ABI, which is bad. >>> >>> Opinions? >> >> After thinking about it more: the WinNT MPM use of this facility still >> seems unnecessary. The same effect could be achieved using an input >> filter which returns the extra data from AcceptEx. >> >> Here's a proof of concept for prefork, which prepends "GET" to data >> received from the socket - no core hacks required. (This is dumb and >> should be more sophisticated, it would need to handle >> AP_MODE_GETBYTES/AP_MODE_GETLINE if possible from the "extra" data >> alone, without always fetching a brigade from the socket) >> >> For mod_ftp the need to replace the socket bucket looks more convincing, >> but still surely a hook calling *out* from the core is better? > > I agree that the it is not strictly necessary that WinNT MPM modifies the > core input filter's brigade. But I don't think that yet another > implementation of AP_MODE_GETBYTES/AP_MODE_GETLINE would be a superior > design. I think we should defer this change to after Paul (or someone else) > has implemented his input filter API redesign proposal from last November, > which would make input filters more lightweight. > > BTW, the reason I didn't make this a hook is trying to be more efficient. But > the difference may be negligible, it's only called once per connection. If > you prefer to change it to a hook, please go ahead. I won't have time in the > next few days. >
