> Am 06.02.2018 um 08:13 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
> Forgive the top-post, Gmail app sucks.
> Thanks for taking the time for tl;dr - it sums up the current situation
> really well.
> I pointed out some months ago that the matching foo in vhosts is weak, since
> we have a 1:1 ip:port relationship. We determined that can change in the next
> iteration to compare a list we already keep. It seems also evident that a
> vhost could have more than one ServerName as long as we track the canonical
> name that the request presented.
> Considering your cases, I'm wondering if the simplest thing is to promote
> <VirtualHost > to a preprocessed, but fully nestable context on trunk?
That is one possible way to address this. However, since VirtualHost requires
at least one address, this would be confusing:
What would NNN be or what would it mean? Would it also be inherited by the
nested vhosts? This is confusing.
From usability point of view, it is superior to introduce a new "section" that
can keep common locations and other settings for sharing. The implementation is
more painful, though. Unsurprisingly, I think of something like this:
* an MD is basically a server_rec plus additional props
* server_rec gets 2 new members "server_rec *child, *sibling" to keep
* server_rec->next contains only leaf server_recs -> base_server->next
contains all VirtualHosts as before
* leaf server_rec->child is NULL
* no nesting of MDs foreseen, disabled, no nesting of VirtualHost
- VirtualHosts server_rec* can be walked as before and all vhost functions see
- Modules should see no change either
- The MD and VirtualHost hierarchy can be traversed by new code starting from
What do you think?
> One, two, three deep VirtualHost server scopes would provide sharing of
> config choices between hosts. Because some of these would be Management
> Scopes, as you suggest, using TAKE_01 would allow an umbrella scope to not
> actually be attached to an interface at all, but just serve, as the global
> context does, for inheritance only hosts.
> Simplest example would be a well scoped http:// interface with a nested
> https:// interface, adding some protected ssl-only content mapping and tls
> config. That would not diminish the outer http:// vhost mapping.
> Similar examples would be a wild card SSL cert config with a number of
> specific content hosts nested within that, sharing the same tls config.
> What this doesn't solve is a many:many mapping. I haven't come up with a good
> answer to that puzzle without resorting to includes and macros, etc.
> On Feb 4, 2018 05:51, "Stefan Eissing" <stefan.eiss...@greenbytes.de> wrote:
> When thinking about adding ACME support to Apache, I felt that the server
> the concept of something "above" VirtualHosts. Something that keeps common
> properties that some VirtualHosts have in common.