> 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: <VirtualHost *:NNN> ServerName example.org <VirtualHost *:80> </VirtualHost> <VirtualHost *:443> </VirtualHost> </VirtualHost> 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: <ManagedDomain example.org> <VirtualHost *:80> </VirtualHost> <VirtualHost *:443> </VirtualHost> </ManagedDomain> Implementation-wise: * an MD is basically a server_rec plus additional props * server_rec gets 2 new members "server_rec *child, *sibling" to keep contained vhosts * 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 no change. - Modules should see no change either - The MD and VirtualHost hierarchy can be traversed by new code starting from base server. What do you think? -Stefan > 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.
