On Thu, Feb 21, 2013 at 06:52:12AM -0600, Eduardo Silva wrote:
> Hi
>
>
> On Wed, Feb 20, 2013 at 3:43 PM, Sonny Karlsson <[email protected]> wrote:
>
> > Hi
> >
> > I've been thinking about a potential project for GSoC 2013, an
> > mk_location core module.
> >
> > The module goal would be to translate an URL to a file location using
> > aliases and rewrites and also limit the number of modules used on a
> > request.
> >
> > The configuration would be located with the vhost information in a
> > location section. I would suggest something like this, but the
> > functionality is more important then the actual syntax.
> >
> > [Host]
> > DocumentRoot /var/www/vhost
> >
> > [Location /doc]
> > Alias /var/www/doc
> >
> > [Location /images]
> > Alias /var/www/images
> > Handler static
> >
> > [Location /users]
> > Rewrite ^/users/{.*}$ /show.cgi?user=$1?
> >
> > [Location /show.cgi]
> > Handler cgi
> >
> > The Handler directive would basically restrict the number of modules
> > which receive the stage30 call. Alias and rewrite would work as they do
> > in apache and nginx.
> >
> > This module would reduce the effort required to produce good plugins for
> > monkey. Plugins would only almost only care about the file path and
> > reduce the chance that two plugins try to render the same resource.
> > With this change, stage_30 could always be trusted to mean that this
> > request should be rendered. Compatibility will not be a problem as
> > current plugins already does location matching. To handle location
> > specific settings would still require plugin changes of course.
> >
> > Producing this module wouldn't require too much effort if posix regex is
> > used. The integration with monkey would probably involve some extra
> > request_session state and refactoring in mk_http/mk_headers. Rewrites
> > should be applied before Alias and multiple Rewrite or Aliases
> > directives on the same Location isn't supported by the configuration
> > format (correct me if I'm wrong). If rewrite changes the location, that
> > too should be handled.
> >
> > I would very much like to see this in monkey!
> >
> >
> Pretty interesting, definitely it makes a lot of sense to reduce the
> overhead where each plugin perform it owns match to handle a specific
> request based in a string comparison.
>
> What i would like to see in a different way, is how this is done in the
> configuration:
>
> [Location /users]
> Rewrite ^/users/{.*}$ /show.cgi?user=$1?
>
> that looks pretty much like an Apache or NginX style, but in Monkey the
> [..] are used to mark a section in the configuration with N rows with 'key
> value' style. Maybe we have to implement a second level of indentation for
> the configuration, i am not very clear about the config stuff at the
> moment, but the functionality and project idea are perfect,
I used [Location arg] in the example as it is possible to implement
without any changes to the configuration parsing and the intension is
clear. If I follow the current configuration format and add a Match key
the functionality is not as obvious. Below is an explanation why and
possible changes to fix it. None of the following is relevant to the
GSoC project.
[Location]
Rewrite ^/{[a-z]+}/{.*}$ /show.cgi?id=$1?
Match /users
Alias /var/www/cgi-bin
This ordering of keys does not intuitively imply that we only rewrite if
Match matches the url. It may as well be that the we always rewrite
everything that can be rewritten. Match would also be required while the
others are not.
I would much rather have a way to register a keyword. A keyword which
may start a section and/or have space delimited arguments. This
function prototype and example use should illustrate the idea.
mk_config_keyword_register(const char *key, int args, int is_section);
mk_config_keyword_register("Host", 1, MK_TRUE);
mk_config_keyword_register("DocumentRoot", 1, MK_FALSE)
mk_config_keyword_register("Location", 1, MK_TRUE);
mk_config_keyword_register("Alias", 1, MK_FALSE);
mk_config_keyword_register("Rewrite", 2, MK_FALSE);
This does however require large changes inside monkey as we'd need to
alter a lot of mk_config's structs and use. But configuration validation
would be possible. I personally would like to go even further and adopt
a style similar to what I've listed below. It is expressive and the
intension is clear, inspired by apache/nginx.
Host localhost {
DocumentRoot "/var/localhost www dir"
Location ^/users {
Rewrite ^/users/{.*}$ /show.cgi?user=$1?
}
Location .cgi$ {
Handler cgi
}
}
>
> best,
>
> --
> Eduardo Silva
> http://edsiper.linuxchile.cl
> http://www.monkey-project.com
--
Sonny Karlsson
_______________________________________________
Monkey mailing list
[email protected]
http://lists.monkey-project.com/listinfo/monkey
