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? 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 lacked the concept of something "above" VirtualHosts. Something that keeps common properties that some VirtualHosts have in common.
