Re: Some ramblings on httpd config
Graham Dumpleton wrote: > Since you are talking here about runtime decisions based on a specific > request, rather than auto generation of the static configuration in > once off phase, it almost sounds like all you need is a way of having > the lua code which would be associated with a specific handler in the > configuration file rather than having to be in a separate file. So, > instead of: > > LuaHookTranslateName lib/hooks.lua trans_name > > allowing something like: > > > function trans_name(r) > ... > end > > > This approach doesn't require any changes to httpd itself as the > ability to do this becomes a feature of just the module supporting > that scripting language, eg, mod_lua. The same could also be done for > other scripting languages. > > So, if your aim is to be able to do everything within the one Apache > configuration file, rather than out in separate scripts, this would > seem in part to satisfy the requirement. I like this. In theory, you could have a mod_java, or anything really. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Some ramblings on httpd config
2009/6/4 Akins, Brian : > On 6/4/09 8:14 AM, "Jorge Schrauwen" wrote: > >> Like Graham mentioned mod_macro can be of some use here. however since >> I'm looping in perl I may as well push the 4 lines needed to httpd >> instead of a one line macro replacemen. > > Okay, I'm not explaining my self well. I'm not just talking about > generating the internal configuration from lua (or xml, or macro, etc.) > > But actually "running" httpd using lua. The request handling is done in lua > - or rather driven by lua. > > See http://redmine.lighttpd.net/projects/lighttpd/wiki/AbsoLUAtion > > A side note: I think the vhost concept we have now is lacking. The > separation that we have just isn't necessary and makes some common tasks > hard. I'm not really willing to fight for this one though ;) I can "fake" > what I want if I can just load up a lua handler to handle the request from > post_read to handler. Since you are talking here about runtime decisions based on a specific request, rather than auto generation of the static configuration in once off phase, it almost sounds like all you need is a way of having the lua code which would be associated with a specific handler in the configuration file rather than having to be in a separate file. So, instead of: LuaHookTranslateName lib/hooks.lua trans_name allowing something like: function trans_name(r) ... end This approach doesn't require any changes to httpd itself as the ability to do this becomes a feature of just the module supporting that scripting language, eg, mod_lua. The same could also be done for other scripting languages. So, if your aim is to be able to do everything within the one Apache configuration file, rather than out in separate scripts, this would seem in part to satisfy the requirement. Graham
Re: add OS to BugZilla
Done by Mark (Thomas) independent of 'Product' category. On 03.06.2009 17:24, Guenter Knauf wrote: > Hi, > we support NetWare already from 1.3.x days, and I think it would make > sense to add 'NetWare' to the OS dropdown selector in BugZilla; > can perhaps someone with the needed karma add this please?
Re: mod_proxy. mod_proxy_balancer and failovers
On Thu, Jun 4, 2009 at 4:32 PM, Jim Jagielski wrote: > Sure... no guarantees that they'll be applied, but it would > be useful to see what you have in mind. Huh. I thought it would be easy as fixing just mod_proxy.c, but... It occurred that mod_proxy_http thinks that, for example, HTTP_INTERNAL_SERVER_ERROR is not an error if body was returned. So for mod_proxy_http only clean errors (without body) are true errors. Did i understood code right? Was that done on purpose? Why? -- Marko Kevac
Re: Some ramblings on httpd config
Absolutely, but since it doesn't come with the product, most folks are never going to see it. Can we get Fabien to contribute it? On Jun 4, 2009, at 07:58, Graham Dumpleton wrote: 1. There are many and large and complex configurations out in the world. Which is exactly why I want/need a better way to do them. I'm currently using a template system to generate them. However I wind up with dozens (and dozens) of vhosts that sometimes only vary by a statement or too. Would mod_macro help. http://www.coelho.net/mod_macro/ Graham -- Just because your voice reaches halfway around the world doesn't mean you are wiser than when it reached only to the end of the bar. Edward R. Murrow
Re: mod_proxy. mod_proxy_balancer and failovers
On Jun 4, 2009, at 4:16 AM, Kevac Marko wrote: So, do we have any conclusion? Should I make modifications and post patch? Sure... no guarantees that they'll be applied, but it would be useful to see what you have in mind.
Re: Some ramblings on httpd config
On 6/4/09 8:14 AM, "Jorge Schrauwen" wrote: > Like Graham mentioned mod_macro can be of some use here. however since > I'm looping in perl I may as well push the 4 lines needed to httpd > instead of a one line macro replacemen. Okay, I'm not explaining my self well. I'm not just talking about generating the internal configuration from lua (or xml, or macro, etc.) But actually "running" httpd using lua. The request handling is done in lua - or rather driven by lua. See http://redmine.lighttpd.net/projects/lighttpd/wiki/AbsoLUAtion A side note: I think the vhost concept we have now is lacking. The separation that we have just isn't necessary and makes some common tasks hard. I'm not really willing to fight for this one though ;) I can "fake" what I want if I can just load up a lua handler to handle the request from post_read to handler. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Some ramblings on httpd config
On 6/4/09 7:51 AM, "Dan Poirier" wrote:
> and having to write a program to
> implement mod_rewrite or a virtual host yourself.
Something like this would be trivial to do:
if prefix_match(r.uri, "/foo/") then
return do_redirect(r, "http://somewhere.else/";)
end
Okay, not a great example, but it's early here :) The fact that
conditionals are just *there* in lua would make some rewrite operations
easier. We could also provide plenty of helper stuff (written in lua,
probably).
rr = httpd.rewrite
rr.rule('/something(.*)', '/other$1')
-- in handler
x = rr.run( r )
if(x != DECLINED) then
return x
end
if r.env["something"] then
return proxy:request(r, "http://some.domain.com";)
end
Like I said, I'm not just thinking of lua as a config, but lua as the
"driver" of httpd. Or at least provide enough glue for some core modules to
allow us "advanced" users to do this. We may not need a whole lot of glue
to start with, a few useful ones:
serve_file(r, "/some/file/on/disk")
x = do_subrequest(r, uri) -- x could contain headers, bucket brigade (or
just a big string)
do_redirect(r, location, 301)
Also, it would be nice if we could redo the mod_lua lua-request_rec glue so
that other modules can "mixin" addition functionality:
require "httpd.util"
r:serve_file("/some/file"
r:redirect(location, 301)
I've been playing with that, but my lua-glue foo is weak. Something about
the way we are handling the metatable and __index doesn't like that.
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: Some ramblings on httpd config
On Thu, Jun 4, 2009 at 1:55 PM, Akins, Brian wrote: > On 6/3/09 7:50 PM, "Plüm, Rüdiger, VF-Group" > wrote: > >> 1. There are many and large and complex configurations out in the world. > > Which is exactly why I want/need a better way to do them. I'm currently > using a template system to generate them. However I wind up with dozens > (and dozens) of vhosts that sometimes only vary by a statement or too. > On this I completely agree! Currently say fetching 100+ hosts from a database that are basicly the same except domain, documentroot and maybe 3 options like has php, has cgi,.. is a PITA. mod_perl with database backend... works I guess but it's like taking a nice car, strip the engine and gut donkey and cram the engine in the donkey. Ok not what I wanted to write but can't describe it. Like Graham mentioned mod_macro can be of some use here. however since I'm looping in perl I may as well push the 4 lines needed to httpd instead of a one line macro replacemen. > A contrived example: > > -- lots of stuff > if r.hostname == "www.domain.com" then > -- a couple of things specific to this domain > elseif r.hostname == "www.domain2.com" then > ... > > > Of course, this example may could have a little lua glue to handle this > situation. > > > Also, I'm not just talking about lua being the config language, I want lua > to "drive" the httpd process. Ie, the above code gets ran on every request. > >> 2. I admit that some improvements are needed. How about an approach that >> allows >> to embed a macro / scripting language into the current configuration >> system >> that allows you to do more advanced things if you need to. > > If we provided enough glue within our modules for lua, this this would be > fairly easy. I already fake this a bit with mod_lua and handlers that do > most of the work. > -- > Brian Akins > Chief Operations Engineer > Turner Digital Media Technologies > > Maybe we're looking at it the wrong way? Why not go more modular with this as well? >From what I've understood from wrowe's explenation the internal config tree seems very flexible so why not create multiple ways to manipulate it? module register "parameters,blocks,..." with the internal config mangement thingy, front ends then configure the modules using those interfaces. It being a flat file, xml file, lua script, perl script,... having little relevance to httpd itself. Flat file would turn that info say for the command into something like Documentroot /some/path Lua format would turn that in something else, whilst an xml format way turn it into /some/path You could keep the current method for legacy use, implement an lua one for more advance use, xml one because somebody was bored and wanted it. Heck even a lolcode one because you could. even mixing could be possible, have some general stuff in flatfile, include a lua script to generate hosts which in its turn include a flat file with shared config for each host. Then again it would be hard to write documentation for this. Since "documenroot" could then have many ways to be set from a users POV :( so maybe not a great idea. But I'm just trowing out the whacky brain twists I have. Jorge
Re: Some ramblings on httpd config
2009/6/4 Akins, Brian : > On 6/3/09 7:50 PM, "Plüm, Rüdiger, VF-Group" > wrote: > >> 1. There are many and large and complex configurations out in the world. > > Which is exactly why I want/need a better way to do them. I'm currently > using a template system to generate them. However I wind up with dozens > (and dozens) of vhosts that sometimes only vary by a statement or too. Would mod_macro help. http://www.coelho.net/mod_macro/ Graham > A contrived example: > > -- lots of stuff > if r.hostname == "www.domain.com" then > -- a couple of things specific to this domain > elseif r.hostname == "www.domain2.com" then > ... > > > Of course, this example may could have a little lua glue to handle this > situation. > > > Also, I'm not just talking about lua being the config language, I want lua > to "drive" the httpd process. Ie, the above code gets ran on every request. > >> 2. I admit that some improvements are needed. How about an approach that >> allows >> to embed a macro / scripting language into the current configuration >> system >> that allows you to do more advanced things if you need to. > > If we provided enough glue within our modules for lua, this this would be > fairly easy. I already fake this a bit with mod_lua and handlers that do > most of the work. > -- > Brian Akins > Chief Operations Engineer > Turner Digital Media Technologies > >
Re: Some ramblings on httpd config
On 6/3/09 7:50 PM, "Plüm, Rüdiger, VF-Group" wrote: > 1. There are many and large and complex configurations out in the world. Which is exactly why I want/need a better way to do them. I'm currently using a template system to generate them. However I wind up with dozens (and dozens) of vhosts that sometimes only vary by a statement or too. A contrived example: -- lots of stuff if r.hostname == "www.domain.com" then -- a couple of things specific to this domain elseif r.hostname == "www.domain2.com" then ... Of course, this example may could have a little lua glue to handle this situation. Also, I'm not just talking about lua being the config language, I want lua to "drive" the httpd process. Ie, the above code gets ran on every request. > 2. I admit that some improvements are needed. How about an approach that > allows >to embed a macro / scripting language into the current configuration system >that allows you to do more advanced things if you need to. If we provided enough glue within our modules for lua, this this would be fairly easy. I already fake this a bit with mod_lua and handlers that do most of the work. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Some ramblings on httpd config
Niklas Edmundsson writes: > Those who can't grasp lua probably couldn't grasp our current config > scheme either. I strongly disagree. There's a huge gulf between being able to describe a configuration with a few directives, and having to write a program to implement mod_rewrite or a virtual host yourself. I really don't want to spend the next however-many-years debugging not only users' configurations, but their programming as well. -- Dan Poirier
Re: Some ramblings on httpd config
Rich Bowen writes: > The directive, along with better documentation, would solve 50% of what > people use mod_rewrite for. A less painful way to configure dynamic virtual > hosts would solve another 15%. And a healthy dose of education about all the > gross misconceptions called "SEO" would solve the rest. > > Yes, we need some kind of macro thingy in the configuration. And while I think > that most of us reading this email thread can handle that thingy being Lua, I > honestly don't believe that the folks over on the users@ list can, unless it's > something that can be embedded into existing configurations, rather than being > the entirety of the configuration. If we can fix the biggest problems with the current configuration scheme, I think that's a powerful argument that we don't need to throw it out and invent a whole new one. As others have said, there's a huge amount of knowledge out there based on the current configuration scheme, and throwing all that out would be a shame. -- Dan Poirier
Re: mod_proxy. mod_proxy_balancer and failovers
So, do we have any conclusion? Should I make modifications and post patch? -- Marko Kevac
