On 24.05.2011 10:23, Issac Goldstand 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
> ...

I like the next more, but in light of your reply to "include" I'm not
sure what you get w.r.t. maintainability compared with includes.

> 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

Do you know about mod_macro?

http://www.cri.ensmp.fr/~coelho/mod_macro/

It exists since a long time and is pretty stable. Might need some update
for 2.3/2.4.

> 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?

That sounds more like a grouping container for VirtualHost, e.g.

<VirtualHostConfig>

SomeOption
SomeOtherOption

<VirtualHost blabla>
ServerName bla
DocumentRoot /foo
<VirtualHost blabla:443>
SSLEngine On
...
</VirtualHost>

</VirtualHostConfig>

But then again very soon you end up with different orthogonal feature
sets you want to assign to vhosts and a simple grouping will no longe
suffice (feature sets A and B can lead to vhosts needing A, needing B,
needing A+B or none). So I think including per VHost still makes more
sense and macros are even better, because they let you parametrize the
included part and thus often the config gets more compact.

Regards,

Rainer

Reply via email to