Remove assumption that project will be run on Apache webserver

[GuySartorelli]

Right now there's a built-in assumption that a Silverstripe CMS project will be run on an Apache webserver.

There are .htaccess files in recipe core, one of which gets updated based on the allowed file types.

We should remove the assumption that the project will be run on Apache. This includes ensuring any configuration is webserver-agnostic, so that developers can spin up a Silverstripe CMS project in any PHP webserver without having to add a bunch of framework-specific configuration.

Possibly related issues

• [4.0] Block access to uploaded error-\d.html files #115
• Root .htaccess doesn't get installed when using the public webroot recipe-core#50
• Silverstripe writes .htaccess files on servers running nginx silverstripe-assets#177
• Rewrite rule in base htaccess is missing [L] #241
• TinyMCE Unavailable ->web.config reset -> IIS problem silverstripe-cms#2292

Acceptance criteria

• .htaccess files are removed
• Any configuration that needs to happen is done in PHP at the earliest point possible
• At least one non-Apache webserver is tested against for at least one module's behat tests

[elliot-sawyer]

I think the best way to remove the assumption it only runs on Apache, is to supply detailed configuration instructions and configuration files. Crowd-source it, allow free contributions to the docs, while insisting on line-by-line comments indicating what each one does and why it is necessary

[andrewandante]

Totally agree with @elliot-sawyer.

The challenge to overcome (I think) is that if this goes ahead, we are suddenly booting the app a lot more often, to handle things like restricted file extensions, by default. Yes, proper documentation will help (i.e. if using Nginx, for best performance, please create this file in this place blah blah) but it will be counter-intuitive (for old Silverstripers, anyway) for a change to config (allowed_file_types or whatever) to not have the effect at the server config level.

I think that's actually a good thing - I'd prefer that to be managed by a SysAdmin, and have the app as a backup plan/safety valve, but it'll need to be clearly spelled out. There'll be times when doing the major upgrade that this requires will introduce security holes, and that needs to be considered carefully.

Did I say I'm massively in favour of this? I am 😄