Do not ship a default .htaccess file about standard-edition HOT 14 CLOSED

@contao/developers Any objections?

Yes, I am against these changes. They make absolutely no sense to me. If the IfModule directive is forbidden (which I don't believe anyway), why would the <IfModule mod_headers.c> be allowed then? We have added a massive amount of hacks (e.g. the SMH) over time in Contao 3.5 just because people were unable to configure their servers properly. This in turn has caused a lot of other issues later on and I want this to be the past. If your server setup does not run Contao, fix it or don't use Contao.

from standard-edition.

It's a default htaccess so you don't have to use it. You have to check before using it, if it's working with the used server configuration. When we support a "standard server configuration" it's not our problem if anybody uses a non standard configuration. Maybe we can add a notice, that anybody have to check the access before using it. ;-)

from standard-edition.

I mostly agree with @Toflar. The file provides a sane configuration for most users, and enables what we can by default. The users that do not support this file are by far a minority, so removing the file would mean >80% (wild guess) of users need to apply a manual change versus 5% that need to remove/change the file.

(the 5% are a wild guess of Apache users that don't support the config file. Nginx is not affected as the file is simply ignored)

from standard-edition.

We would still be shipping the file of course. Only not enable it by default, which seems a fair compromise to me.

from standard-edition.

I agree with @aschempp and @Toflar and think we should keep the .htaccess as it is.

If there is an issue with this .htaccess file on certain Apache setups, we should try to debug and fix it if possible or otherwise write down that a specific Apache configuration is not supported.

I’m interested which Apache setup has issues with <IfModule mod_rewrite.c>...

from standard-edition.

But this means that some users install Contao and only get an internal server error without further explanation. Not very user friendly, is it?

from standard-edition.

Correct. They will get that if their server does not support the (default) Contao. They also will if they use PHP 5.3, or whatever else if their server is incompatible…

from standard-edition.

Then why do we ship an .htaccess.default file in Contao 3.5? We might as well ship a regular .htaccess file and just stop caring about people with incompatible server setups! #kannsteschonsomachen

from standard-edition.

Not true. We shipped a .htaccess.default because otherwise the file would be overwritten on a (live-)update. That's no longer the case with Contao 4.

from standard-edition.

Nope. The .htaccess.default file existed before the Live Update for exactly this reason.

from standard-edition.

The issue can be split into two different problems:

1. AllowOverride -FileInfo
2. AllowOverride -Indexes

We cannot do much about 1., because neither Contao 4 nor Contao 3 will work with this configuration. But 2. is a legit configuration, which we should support. I am therefore going to change the .htaccess file as follows:

<IfModule mod_headers.c>
    # Allow access from all domains for webfonts (see contao/core-bundle#528)
    <FilesMatch "\.(ttf|ttc|otf|eot|woff2?|font\.css)$">
        Header set Access-Control-Allow-Origin "*"
    </FilesMatch>
</IfModule>

<IfModule mod_rewrite.c>
    RewriteEngine On

    # Determine the RewriteBase automatically and set it as environment variable.
    # If you are using Apache aliases to do mass virtual hosting or installed the
    # project in a subdirectory, the base path will be prepended to allow proper
    # resolution of the app.php file and to redirect to the correct URI. It will
    # work in environments without path prefix as well, providing a safe, one-size
    # fits all solution. But as you do not need it in this case, you can comment
    # the following 2 lines to eliminate the overhead.
    RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$
    RewriteRule ^(.*) - [E=BASE:%1]

    # Sets the HTTP_AUTHORIZATION header removed by Apache
    RewriteCond %{HTTP:Authorization} .
    RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect to URI without front controller to prevent duplicate content
    # (with and without `/app.php`). Only do this redirect on the initial
    # rewrite by Apache and not on subsequent cycles. Otherwise we would get an
    # endless redirect loop (request -> rewrite to front controller ->
    # redirect -> request -> ...).
    # So in case you get a "too many redirects" error or you always get redirected
    # to the start page because your Apache does not expose the REDIRECT_STATUS
    # environment variable, you have 2 choices:
    # - disable this feature by commenting the following 2 lines or
    # - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
    #   following RewriteCond (best solution)
    RewriteCond %{ENV:REDIRECT_STATUS} ^$
    RewriteRule ^app\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]

    # If the requested filename exists, simply serve it.
    # We only want to let Apache serve files and not directories.
    RewriteCond %{REQUEST_FILENAME} -f
    RewriteRule ^ - [L]

    # Rewrite all other queries to the front controller.
    RewriteRule ^ %{ENV:BASE}/app.php [L]
</IfModule>

<IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>
        # When mod_rewrite is not available, we instruct a temporary redirect of
        # the start page to the front controller explicitly so that the website
        # and the generated links can still be used.
        RedirectMatch 302 ^/$ /app.php/
        # RedirectTemp cannot be used instead
    </IfModule>
</IfModule>

With these changes, the .htaccess file worked fine on my machine.

from standard-edition.

Changed in da86061.

from standard-edition.

So basically you remove DirectoryIndex, right? Why not keep the IfModule mod_negotiation.c part?

from standard-edition.

Because we should not mess with the Options setting, either. It should be configured on server level, not on vhost level.

from standard-edition.