Because when you've got tens or hundreds of vhosts, or generate the conf, that often becomes hell to manage.
On 24/05/2011 14:44, Ondřej Surý wrote: > Why not: > > <VirtualHost foo:80> > include name-host.conf > </VirtualHost> > > <VirtualHost foo:443> > ssl_stuff > include name-host.conf > </VirtualHost> > > On 24.5.2011, at 10:23, Issac Goldstand <mar...@beamartyr.net> wrote: > >> A feature that I've kinda wanted for a long time has been the ability to >> alias and/or extend existing virtualhosts. Previously, this was just a >> minor pain that usually just came up when setting up a website with dual >> http and https. It was a bit more of a pain if the virtualhost config >> needed substantially more than servername, documentroot and maybe logs >> and scriptalias. >> >> Lately I've started adding native IPv6 support to many of my websites, >> and given that now I occasionally have to manage the same config lines 4 >> times, the annoyance factor's gotten big enough to get me to stop >> whining and start coding. >> >> I had 4 ideas so far, and wanted to hear some feedback. >> >> The first idea is Lua, but IMHO (and I imagine that a LOT of you will >> disagree), lua configs aren't really going anywhere (and won't until not >> only we start using it in the default configs, but also downstream >> vendors keep it in THEIR default configs). >> >> My second idea was to add a feature allowing you to "tag" a virtualhost >> with a unique string. Later you can "import" all of those settings into >> somewhere else. An example would be: >> >> <VirtualHost foo:bar name> >> ... >> <VirtualHost baz> >> ApplyNamedSetting name >> ... >> >> or maybe the tagging would be with a directive like: >> <VirtualHost foo:bar> >> TagNamedSetting name >> >> My third thought was similar. Create a new settings container, and >> allow that to be used as a macro anywhere else: >> >> <NamedSettings name> >> SomeOption >> SomeOtherOption >> </NamedSettings> >> >> ... >> (anywhere else in httpd.conf) >> ApplyNamedSettings Name >> >> My fourth idea was to allow nested virtualhosts (innermost ones get >> settings from outer ones merged in), but I didn't like it as much >> because my gut says it's not a simple enough solution (KISS). >> >> <VirtualHost ::1> >> <VirtualHost blabla> >> ServerName bla >> DocumentRoot /foo >> <VirtualHost blabla:443> >> SSLEngine On >> ... >> </VirtualHost> >> </VirtualHost> >> </VirtualHost> >> >> >> Thoughts? >> >> Issac >> >>
