mtrueblood mtrueblood - 10 months ago 64
PHP Question

Rewrite rules not working as expected with apache 2.4.23

I am using Virtual Box VM and Vagrant to create an Ubuntu 14 box and have no choice but to use apache 2.4.23 as a web server. My app has a front controller (index.php) that is handles most of the work of the site in terms of routing, but there are some standard files that users can access as well.

There are other devs on my team that still have apache 2.4.20 and their boxes are working exactly as expected.

My problem is that the rewrite rules aren't acting as expected. Here is the .htaccess file before upgrading to 2.4.23:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_URI} ^system.*
RewriteRule ^(.*)$ /index.php/$1 [L]

RewriteCond %{REQUEST_URI} ^application.*
RewriteRule ^(.*)$ /index.php/$1

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) /index.php/$1 [L]

Options All -Indexes


<IfModule !mod_rewrite.c>
ErrorDocument 404 /index.php

Here is the apache2.conf:

# Security
ServerTokens OS
ServerSignature On
TraceEnable On

ServerName "my-local"
ServerRoot "/etc/apache2"
Timeout 120
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15

User www-data
Group www-data

AccessFileName .htaccess
<FilesMatch "^\.ht">
Require all denied

<Directory /var/www/>
Options FollowSymLinks
AllowOverride None
Require all granted

HostnameLookups Off
ErrorLog "/var/log/apache2/error.log"
LogLevel warn
EnableSendfile Off

#Listen 80

Include "/etc/apache2/mods-enabled/*.load"
Include "/etc/apache2/mods-enabled/*.conf"
Include "/etc/apache2/ports.conf"

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combi$
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

IncludeOptional "/etc/apache2/conf.d/*.conf"
IncludeOptional "/etc/apache2/sites-enabled/*"

I can access the site as long as I add
to the Rewrite rule, but that is clearing out POST. I tried using GET as a quick workaround, but some of my forms end up with request strings that are too long for apache.

I need to know if there is a flaw in these configs that I am unable to see or if there is a workaround that I am unaware of.

Answer Source

The following got me past the problem:

  • Re-provisioned to Ubuntu 16
  • Added custom_fragment: /var/www/AudiMoc/htaccess to apache in my config.yaml

in htaccess:

## Custom fragment.
## This file can be refered to by the 'apache:' section config.yaml in case of a bug described by
## If you use it, then remove or rename /var/www/AudiMoc/.htaccess.
<IfModule mod_rewrite.c>
    RewriteEngine On
    #Removes access to the system folder by users.
    #Additionally this will allow you to create a System.php controller,
    #previously this would not have been possible.
    #'system' can be replaced if you have renamed your system folder.
    RewriteCond %{REQUEST_URI} ^system.*
    RewriteRule ^(.*)$ /index.php/$1 [L]
    #When your application folder isn't in the system folder
    #This snippet prevents user access to the application folder
    #Submitted by: Fabdrol
    #Rename 'application' to your applications folder name.
    RewriteCond %{REQUEST_URI} ^application.*
    RewriteRule ^(.*)$ /index.php/$1
    #Without this, rewrite_mod will think that '/' matches the directory /var/www/AudiMoc/.
    RewriteRule ^/$ /index.php [L]
    #Checks to see if the user is attempting to access a valid file,
    #such as an image or css document, if this isn't true it sends the
    #request to index.php
    RewriteRule ^(.*)$ /index.php/$1 [L]
<IfModule !mod_rewrite.c>
    # If we don't have mod_rewrite installed, all 404's
    # can be sent to index.php, and everything works as normal.
    # Submitted by: ElliotHaughin
    ErrorDocument 404 /index.php

There was a bug for apache2.4.23-5 that made the [R,L] a must, and the reason I couldn't get around it more easily was because I have to have my dev environment on virtual box using puphpet to build the config. only had one version of apache2 in the repository they reference, so I couldn't get around the bug.

The custom fragment allowed me to get around the problem.