httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <mar...@beamartyr.net>
Subject Re: RFC: aliasing/overriding virtualhosts/setting blocks
Date Tue, 24 May 2011 11:51:22 GMT
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 <margol@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
>>
>>


Mime
View raw message