httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Gruno <>
Subject Re: Ideas for an output filter for mod_lua
Date Wed, 22 Aug 2012 21:25:01 GMT
On 08/22/2012 01:36 PM, Nick Kew wrote:
> Basic concept looks fine.  I guess we'd need more detail
> to say any more about it.
> Is the implementation 'clean' or does it involve hacks to core?
> If what you have is pure module then I'd see no reason
> not to drop mod_lua_filter (or is it mod_filter_lua?)
> into trunk on CTR.

I don't see why it should be made a separate module - it relies and
operates on the stuff already inside mod_lua, and making it a part of it
only requires adding some 50-60 lines of code (ymmv). But ideas/opinions
are of course welcome.

As for the 'cleanliness' of the code, there are no hacks, it works
similar to how the other hook functions in mod_lua work. Each call to a
Lua(In|Out)putFilter would register a new filter with a callback to fx
ap_lua_output_filter, which will then traverse a list of known
scripts/handles, find the one associated with the filter name in
question and run it, making the Lua script yield whenever it's parsed a
bucket and sending it further down the chain. Apart from the actual
bucket handling, the function and the directives behave just as the
other hooks and the LuaMapHandler does. When called, it would register a
file/function in an array, and when a call is made to that handler, it
checks to see what is being called, and finds the file/function
associated with it.

i.e. if you had two directives:
LuaOutputFilter filterA /www/filters.lua filter_a_func
LuaOutputFilter filterB /www/filters.lua filter_b_func

then an output, with any of those two filters attached, would call
ap_lua_output_filter, which would look up the filter currently being run
and then run the file/function mapped to that filter. I guess what
separates this from the other hooks the most is that it relies on
co-routines (aka non-blocking/event-based or whatever the newest buzz
word for it is) to get the job done.

> Meanwhile, some random thoughts:
> Is there a deep reason to limit it to output filters, or is that
> just what you happen to have implemented?

The same method could be applied to input filters as well, I just had an
interest in trying it out for output filters, so that's what I hacked
together before making this proposal. I'll try implementing an input
filter tomorrow.

> Would your concept meaningfully generalise beyond
> application-level filters?

I'm not entirely sure what you mean by this, could you elaborate?
If you want some more sophisticated examples of what could be achieved
with Lua filtering, I'd be happy to provide some more details on how
this concept could be utilised.

With regards,

View raw message