Re: Interpolating %{variables} in all directives
Le Thu, 18 Apr 2013 11:29:29 -0400,
Rich Bowen rbo...@rcbowen.com a écrit :
On Apr 18, 2013, at 11:09 AM, Igor Galić wrote:
From an IRC conversation in #httpd and #httpd-dev emerged the
idea to interpolate %{variables} in all directives.
According to sf we have somewhere a ~10 line code fragment
which does that without much overhead (not benchmarked) when
interpolating and with hardly any (short-circuit) when not.
I think it would be a good idea to allow for this to be used
in all directives (across all modules) it makes for immensly
more readable configurations because:
Example:
# default vhost redirecting every HTTP vhost to HTTPS:
VirtualHost *:80
Redirect / https://%{HTTP_HOST}/
/VirtualHost
Another example might be something more advanced like:
# group specific authorization:
LocationMatch ^/(?Pgroup[^/]+).*
Require group %{group}
/Location
This would be lovely, and make us as cool as nginx.
Problems to address include conflicts with mod_macro, mod_rewrite,
and any third-party module which might do variable fu.
Having the interpolation ignore stuff starting with Rewrite* or in a
mod_macro definition seems simple enough. Having a generic way for a
third-party module to say don't interpolate me, man! could be handy
too.
Hi,
I see no reason why it should be enabled per module, as I guess some
admins might want it for some parts of config, and not others (including
the .htaccess performance parsing point).
How about introducing a new Interpolate context ?
Default : off
Possibly a AllowOverride Interpolate, so the main admin decides
whether .htaccess can make the server really slow.
Also solves the rewrite/macro conflicts issues at the config level :
Interpolate On
Directory /foo/bar
... interpolated stuff
/Directory
/Interpolate
Interpolate Off
Directory /foo/bar
... My rewrite/macro/etc stuff
/Directory
/Interpolate
This would also be fully compatible with 2.X existing configs and
respect their behaviour as long as nothing is changed.
Last point, who knows, maybe using interpolation together with
mod_macro/mod_rewrite will be the next great thing that we didn't think
of, and this config will even let super clever admins invent it for
us ;)
I suppose this might require more work to implement, though.
Vincent
--
Stop chasing shadows, just enjoy the ride.
Morcheeba
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Hi Daniel, On 20.04.2013 08:58, Daniel Gruno wrote: Thanks for the invaluable help, it's really good knowing there's someone else taking such an interest in this project! :) I hope that someday we can shed mod_lua of its experimental status and people won't think me a crazy person for recommending it left and right ;) naa, I find the module useful too for all sorts of smaller tasks as well as special httpd things which otherwise can only be done with a C module I believe ... now since I looked a bit at the code here and there I think there are some things which we should fix over the next months ... 1) the code formatting is not yet at our standard 2) the 'apache2' module does pollute the global table, and at 1st glance with my limited Lua experience I dont see why this happens; I've tested with other dynamically loaded modules like geoip, socket and apr (yeah, there exists a *very* *great* APR binding! [1]), and they all only create their own table and nothing global; it would be nice if we could either teach the apache2 module to behave same, or at least make it prelinked/preloaded and let it only plug in when enabled via 'require'. See attached script which shows what I mean ... 3) Since there exists a well done and well functioning APR binding we should probably consider to add some code to mod_lua so that its possible to prelink/preload this APR binding once at module start instead of loading it from every script again and again ... if we would agree on that we could even ditch a bunch of the recent APR adds, thus making mod_lua itself cleaner / smaller again + we would get almost the full power of APR into mod_lua ... Gün. [1] http://peterodding.com/code/lua/apr/ --[[ Check the package tables --]] --[[ This is the default method name for Lua handlers, see the optional function-name in the LuaMapHandler directive to choose a different entry point. --]] function handle(r) local function print(...) r:puts(... .. \n) end r.content_type = text/plain --local apr = require apr --local geoip = require geoip r:puts( (package.path=%q\n):format(package.path) ) r:puts( (package.cpath=%q\n):format(package.cpath) ) print(\n* Contents of table package:) for k, v in pairs(package) do print( (%s=%q):format(k, tostring(v)) ) end print(\n* Contents of table package.loaded:) for k, v in pairs(package.loaded) do print( (%s=%q):format(k, tostring(v)) ) end print(\n* Contents of table package.preload:) for k, v in pairs(package.preload) do print( (%s=%q):format(k, tostring(v)) ) end print(\n* Contents of table package.loaders:) for k, v in pairs(package.loaders) do print( (%s=%q):format(k, tostring(v)) ) end print( (\npackage.loaded.version=%q):format(package.loaded.version) ) print( (\napache2.version=%q):format(tostring(apache2.version)) ) end
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
On 23.04.2013 23:49, Guenter Knauf wrote: Hi Daniel, On 20.04.2013 08:58, Daniel Gruno wrote: Thanks for the invaluable help, it's really good knowing there's someone else taking such an interest in this project! :) I hope that someday we can shed mod_lua of its experimental status and people won't think me a crazy person for recommending it left and right ;) naa, I find the module useful too for all sorts of smaller tasks as well as special httpd things which otherwise can only be done with a C module I believe ... now since I looked a bit at the code here and there I think there are some things which we should fix over the next months ... 1) the code formatting is not yet at our standard 2) the 'apache2' module does pollute the global table, and at 1st glance with my limited Lua experience I dont see why this happens; I've tested with other dynamically loaded modules like geoip, socket and apr (yeah, there exists a *very* *great* APR binding! [1]), and they all only create their own table and nothing global; it would be nice if we could either teach the apache2 module to behave same, or at least make it prelinked/preloaded and let it only plug in when enabled via 'require'. See attached script which shows what I mean ... 3) Since there exists a well done and well functioning APR binding we should probably consider to add some code to mod_lua so that its possible to prelink/preload this APR binding once at module start instead of loading it from every script again and again ... if we would agree on that we could even ditch a bunch of the recent APR adds, thus making mod_lua itself cleaner / smaller again + we would get almost the full power of APR into mod_lua ... Gün. [1] http://peterodding.com/code/lua/apr/ and two more things: 1) I found with my script that there is also a table apr_table created with methods get and set but its not yet documented 2) I wonder why we do export some functions from mod_lua, and what could make use of these? But then again this is only a Lua newbie question, and I dont know enough about the load process of mod_lua specially on Windows with its external dependency to the Lua DLL and how this exactly works, probably these exports are needed for Windows? Gün.
