Currently, Aphront passes all requests to a single, overloadable `AphrontApplicationConfiguration` object to construct controllers. This object handles a lot: routing domains, building path routing maps, routing the paths, and ultimately generating a controller to handle the request.
This is a big hard-coded mess -- particularly the domain handling. It's also a lot of Phabricator-specific code in an Aphront class. The class name `AphrontApplicationConfiguration` also makes fairly little sense.
A better approach might be to have an abstract base `AphrontPlatform` or `AphrontVirtualHost` or `AphrontSite` class. In the general case, each `Site` might handle a HTTP host, allowing the application to act like Apache VirtualHosts. The code would look roughly like:
```
$sites = AphrontSite::loadAllEnabledSites();
foreach ($sites as $site) {
if ($site->canHandleRequest($request)) {
return $site->buildControllerOrMapOrWhatever($request);
}
}
return 400 response;
```
Phabricator could then define several `Sites` (one for the main application, one for users files, one for Phame blogs, one for Conduit interconnections). In the broader case where Aphront is used generically, whatever's built on top of it could be implemented flexibly. For T1315, this is the path forward to having a homogenous pool of hosts that serve all of the different installs.