Hey Everyone, it looks like filters are coming along well. I'm going to
add a couple of "pseudo-states" that'll let Filter intercept handler
responses and some support for hooking in your own control port commands
if you want people to control them.
First though, I need to let people actually configure them and put them
some place. I'd like feedback on the following proposed docs:
------
Filters are always loaded out of /usr/local/share/mongrel2/filters and
the files are named the same as the filter used in the configuration.
Filters are only loaded if they're actually used in a Server
configuration, so you can have many more filters in this directory than
you actually use.
To configure a filter, you simply add it to the Server.filters attribute
of your Server configs. This attribute is just a list with a mapping of
the filter's name to the dict of options it gets when it's loaded.
Here's an example of configuring the compression filter:
Server(
filters = [
{"compression": { "level": 9, "routes": "/"}}
]
)
This will tell the compression filter to use compression level 9 and try
to compress everything that comes out of /. A list is used so you can
control the order that filters run in, since some might not work if
they come before or after other filters.
Since it's common to what to have global defaults for some filters, you
can also set a filters = {} in the main file to set defaults. Here's an
example of saying the default for compression level is 5:
filters = { "compression": {"level": 5} }
In this case, the Server configuration above would still have a
compression level of 9, since it overrides the defaults, but if you did
this:
Server(
filters = [ {"compression": {"routes": "/" }} ]
)
Then it would just assume the default level of 5.
--------
That I believe is a good start, but let me know what people think of
that format and how it's used. I could also see:
Server(
filters = { "compression": { "level": 9, "routes": "/"} }
filters_order = ["compression", "blah"]
)
Or other suggestions are welcome.
--
Zed A. Shaw
http://zedshaw.com/
2011/5/18 Zed A. Shaw <zedshaw@zedshaw.com>: > Hey Everyone, it looks like filters are coming along well. I'm going to > add a couple of "pseudo-states" that'll let Filter intercept handler > responses and some support for hooking in your own control port commands > if you want people to control them. > > First though, I need to let people actually configure them and put them > some place. I'd like feedback on the following proposed docs: > > ------ > Filters are always loaded out of /usr/local/share/mongrel2/filters and > the files are named the same as the filter used in the configuration. > Filters are only loaded if they're actually used in a Server > configuration, so you can have many more filters in this directory than > you actually use. Using this path will be impossible to load/unload or enable/disable a filter at runtime (via control command). After mongrel2 chroots this path will not exist. Do you think this will be a problem? > To configure a filter, you simply add it to the Server.filters attribute > of your Server configs. This attribute is just a list with a mapping of > the filter's name to the dict of options it gets when it's loaded. > Here's an example of configuring the compression filter: > > Server( > filters = [ > {"compression": { "level": 9, "routes": "/"}} > ] > ) > > This will tell the compression filter to use compression level 9 and try > to compress everything that comes out of /. A list is used so you can > control the order that filters run in, since some might not work if > they come before or after other filters. > When this list is inserted into the config database, what will be the "order by" clause of the select that will get this list? Will it use the "id" from the filter table or this table will have a "exec_order" column? > Since it's common to what to have global defaults for some filters, you > can also set a filters = {} in the main file to set defaults. Here's an > example of saying the default for compression level is 5: > > filters = { "compression": {"level": 5} } > The global config for a filter will be stored in which table? settings? Looking forward to see this in mongrel2! Already have two filters to write! =) -- Dalton Barreto http://daltonmatos.wordpress.com http://wsgid.com
On Wed, May 18, 2011 at 09:49:23PM -0300, Dalton Barreto wrote: > 2011/5/18 Zed A. Shaw <zedshaw@zedshaw.com>: > > Filters are always loaded out of /usr/local/share/mongrel2/filters and > > the files are named the same as the filter used in the configuration. > > Filters are only loaded if they're actually used in a Server > > configuration, so you can have many more filters in this directory than > > you actually use. > > Using this path will be impossible to load/unload or enable/disable a > filter at runtime (via control command). After mongrel2 chroots > this path will not exist. > Do you think this will be a problem? It's going to load them before the chroot, and I'm not going to support hot reloading of filters. Way too dangerous since they're linked in C libraries. > > This will tell the compression filter to use compression level 9 and try > > to compress everything that comes out of /. A list is used so you can > > control the order that filters run in, since some might not work if > > they come before or after other filters. > > > > When this list is inserted into the config database, what will be the > "order by" clause of the select > that will get this list? Will it use the "id" from the filter table or > this table will have a "exec_order" column? Not sure, but yeah probably ordered by the id. > The global config for a filter will be stored in which table? settings? Probably settings, but it'll be merged into the server's config in the filter table, so mongrel2 won't be doing this on the fly I think. > Looking forward to see this in mongrel2! Already have two filters to write! =) What are they? -- Zed A. Shaw http://zedshaw.com/
2011/5/18 Zed A. Shaw <zedshaw@zedshaw.com>: > On Wed, May 18, 2011 at 09:49:23PM -0300, Dalton Barreto wrote: >> 2011/5/18 Zed A. Shaw <zedshaw@zedshaw.com>: >> > Filters are always loaded out of /usr/local/share/mongrel2/filters and >> > the files are named the same as the filter used in the configuration. >> > Filters are only loaded if they're actually used in a Server >> > configuration, so you can have many more filters in this directory than >> > you actually use. >> >> Using this path will be impossible to load/unload or enable/disable a >> filter at runtime (via control command). After mongrel2 chroots >> this path will not exist. >> Do you think this will be a problem? > > It's going to load them before the chroot, and I'm not going to support > hot reloading of filters. Way too dangerous since they're linked in C > libraries. > What threats do you see about this load/reload stuff at runtime? Just the possibility to crash mongrel2 after it has successfully started or is there any security problem? >> > This will tell the compression filter to use compression level 9 and try >> > to compress everything that comes out of /. A list is used so you can >> > control the order that filters run in, since some might not work if >> > they come before or after other filters. >> > >> >> When this list is inserted into the config database, what will be the >> "order by" clause of the select >> that will get this list? Will it use the "id" from the filter table or >> this table will have a "exec_order" column? > > Not sure, but yeah probably ordered by the id. > Good. >> The global config for a filter will be stored in which table? settings? > > Probably settings, but it'll be merged into the server's config in the > filter table, so mongrel2 won't be doing this on the fly I think. > Mongrel will do this merge whenever it boots? Or this merge will be done my m2sh when loading a config file into a config database? I'm asking this because suppose you have an already created config.sqlite and just inserts a new reg in the settings table: it's a global config for the 'gzip' filter (eg. compress = 9). An then I just start adding filters to other servers. When mongrel2 starts, this config values will me merged and the filter table will be updated? Or mongrel2 will just merge the values in memory? >> Looking forward to see this in mongrel2! Already have two filters to write! =) > > What are they? > Well, this first will be kind of an experiment. I was thinking about implementing ticket 92c09e959e [1] ("Support Expect:100 crap.") as a filter. I said experiment because I believe this feature belongs to core mongrel2, but this would be a nice exercise for a first "real-life" filter. The other would be a memcached filter, that just looks at every request/response and tries to find any hint about the possibility of that response be cached. What do you think? [1] http://mongrel2.org/tktview?name=92c09e959e -- Dalton Barreto http://daltonmatos.wordpress.com http://wsgid.com
> Filters are always loaded out of /usr/local/share/mongrel2/filters and > the files are named the same as the filter used in the configuration. Are you asserting that path be hard-coded? If so I'd rather like to see it behave closer to a project built with ./configure --prefix=.. to specify the /usr/local component, defaulting to "/usr/local". Though, since mongrel2 doesn't use autotools, could it be specified as a var to make? -- Slava
On Wed, May 18, 2011 at 07:30:36PM -0400, Yaroslav Shirokov wrote: > > Filters are always loaded out of /usr/local/share/mongrel2/filters and > > the files are named the same as the filter used in the configuration. > > Are you asserting that path be hard-coded? If so I'd rather like to see it behave closer to a project built with ./configure --prefix=.. to specify the /usr/local component, defaulting to "/usr/local". Though, since mongrel2 doesn't use autotools, could it be specified as a var to make? Yeah, it'd be $DESTDIR$PREFIX/share/mongrel2 -- Zed A. Shaw http://zedshaw.com/