1

System specifications:

  • Amazon Linux AMI release 2017.03

  • Apache/2.4.33 (Amazon)

  • PHP 5.6.36

  • DNS is handled by Cloudflare

Here are my VirtualHosts:

<VirtualHost *:80>
    DocumentRoot "/var/www/sub.mysite.com/app/public"
    ServerName sub.mysite.com

    <Directory "/var/www/sub.mysite.com/app/public">
        Options -Indexes +FollowSymLinks +MultiViews
        AllowOverride All
    </Directory>
</VirtualHost>

<VirtualHost *:443>
    DocumentRoot "/var/www/sub.mysite.com/app/public"
    ServerName sub.mysite.com

    SSLEngine on
    SSLCertificateFile /ssl/mykey.crt
    SSLCertificateKeyFile /ssl/mykey.key
    <Directory "/var/www/sub.mysite.com/app/public">
        Options -Indexes +FollowSymLinks +MultiViews
        AllowOverride All
    </Directory>
</VirtualHost>

And the .htaccess that lives within that public directory:

<IfModule mod_rewrite.c>
    <IfModule mod_negotiation.c>
        Options -MultiViews
    </IfModule>

    # Redirect Trailing Slashes If Not A Folder...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)/$ /$1 [L,R=301]

    # Handle Front Controller...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]

    # Handle Authorization Header
    RewriteCond %{HTTP:Authorization} .
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
</IfModule>

This is a Laravel(PHP) application, meaning that the "public" directory referenced above for the DocumentRoot for my VirtualHost contains an index.php script that is the entrypoint to the application and a .htaccess file which pushes all requests to that script.

I've confirmed that mod_rewrite is enabled both via apachectl -D DUMP_MODULES and phpinfo. As you can see above AllowOverride All is set. The permissions for the file also appear to be correct - if I use this script in /public, I get the expected results(.htaccess exists and is readable by the webserver).

However, as far as I can tell the .htaccess is ignored. For example: if I make a request to https://sub.mysite.com/admin/login, Apache appears to look for that path as an explicit file(when it would normally be pushed over to index.php) - excerpt from the global apache error_log:

AH00128: File does not exist: /var/www/sub.mysite.com/app/public/admin/login

If I make an arbitrary PHP script under that public directory and browse to it directly, that script will run as expected.

For what it's worth, I don't think this is a Cloudflare issue - if I hardcode the actual server's IP in my hostfile with the domain, I get the same exact behavior, and I can confirm that the browser is going directly to the server in that scenario and not passing through cloudflare.

So, the Cloudflare DNS A record is working - I'm getting to the server. The VHosts appear to be working, since apache is looking for files in the correct document root. It's just as though apache is ignoring the .htaccess file in that directory, which should take anything in the path of the URL and push it over to the index.php script.

How can I tell if apache is even aware of the .htaccess, let alone parsing it?

Edit: per suggestions in the comments I tried adding some junk to the .htaccess file to see if apache coughed up an error page - no luck. Same behavior. As a control I tried this on a different(working) server and saw the normal Apache error page complaining about misconfiguration. So this tells me that apache either does not see or is purposefully disregarding my .htaccess.

jvnk
  • 123
  • 4
  • Add some "nonsense" to the very top of your `.htaccess` file (before the `` wrapper) - do you get an error? You should also disable `MultiViews` in the vHost (ie. use `-MultiViews`, not `+MultiViews`), not enable it! You are disabling this in `.htaccess` - but it is contradictory. – MrWhite Apr 10 '19 at 17:24
  • I've actually tried that too, unfortunately... no dice. Same behavior with or without the junk in .htaccess. So I guess that tells me apache is either not aware of or purposefully ignoring that file. I also removed Multiviews from the vhost per your suggestion as well, though I think that's unrelated. – jvnk Apr 10 '19 at 17:42
  • For kicks I also created a subdirectory under /public with its own .htaccess with junk in it. Same result. – jvnk Apr 10 '19 at 17:48
  • Is it possible that `AllowOverride` (or `AllowOverrideList`) is set elsewhere on your system, which is overriding your directives? Is `AccessFileName` set in the server config to something other that `.htaccess`? – MrWhite Apr 18 '19 at 23:41

0 Answers0