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.