For a variety of reasons (e.g. performance) one might want to serve user-uploaded files, aggregated CSS files, etc from a separate domain from the main Drupal site. Obviously this would not generally be suitable for private downloads without employing additioanl authentication methods that might be beyond the scope of Drupal core.

Currently Drupal allows you to set the file system path outside the docroot, but does not have any way to cleanly set those files to be served from a different domain. Note that clearly to make this work there would need to be various server setup or cross-server file syncing, but these hurdles would be overcome more easily if core provided for the possibility of one (or several) different domains to use for downloads.

Comments

drewish’s picture

Status: Active » Closed (duplicate)

there's several issues where people are working on this type of functionality. one that seems relevant is: #214934: file_url() and hook_file_server()

c960657’s picture

With private files, you can hook into URL generation using custom_rewrite_url_outbound, including changing the domain. This is currently not possible with public files, but it could soon be if you help review the patch in #207310: Allow rewriting of file URL's using custom_url_rewrite_outbound() :-)

Obviously this would not generally be suitable for private downloads without employing additioanl authentication methods that might be beyond the scope of Drupal core.

I think it could actually work with private files in a fairly simple setup: Imagine a site, example.com, that runs on several web servers in a cluster. Files are only stored on one server, static.example.com. The static server shares the same domain as the cluster servers, so it has access to the session cookie and can thus provide authentication using the built-in methods. People uploading files would have to upload them to the static server, but if there was only a few admins uploading files to the site, the could be told to log on to static.example.com manually.