Page MenuHomePhabricator

Make Aphront "virtual hosts"/sites modular
Closed, ResolvedPublic


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.

Event Timeline

epriestley renamed this task from Make "virtual hosts" modular to Make Aphront "virtual hosts"/sites modular.
epriestley claimed this task.
epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added a project: Aphront.
epriestley added subscribers: epriestley, wrotte.

From T5844, the return 400 response; behavior outlined above is currently fairly bad:

  • it's a super-broken-looking text page; and
  • it's an HTTP 500, not an HTTP 400.

It should be a nice simple "here are the domains you can actually use" 400 page instead.

We need this, at a minimum, to unblock host-based configuration. We might need some more work after this, too.

The SiteConfig mechanism might let us get away without really taking this too far, since it acts really early in the stack and can sort of end run around the handling here. I expect I'll push this forward a bit more but probably not get it to a really polished state before launch.