I'm in the process of building an MVC web application using the Zend framework and I've encountered an odd problem.
If I have the httpd.conf VirtualHost section and the web site's root .htaccess file configured one way, Apache does not read the index.php file (i.e. www[dot]mywebsite[dot]com/ fails), writes nothing to the rewrite log and places this error in the general error log file:
Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden: /hg/software/cims/src/public/
Yet, again with the same httpd.conf and .htaccess settings, I can get to my login screen (i.e. www[dot]mywebsite[dot]com/account/login succeeds) and there is plenty of information in the rewrite log.
However, if I move the .htaccess rewrite commands to the Directory block under VirtualHost and set AllowOverride to "None", the reverse happens. Apache reads and displays index.php (i.e. www[dot]mywebsite[dot]com/ succeeds), but it does not take me to the login screen and attempts to directly access the login screen fail (i.e. www[dot]mywebsite[dot]com/account/login fails).
Thee relevant settings for the first error condition:
httpd.conf:
RewriteEngine On
RewriteLog /hg/hgweb/logs/appdev_rewrite.log
RewriteLogLevel 1
<VirtualHost *:80>
SetEnv ETSSERVER mywebsite
SetEnv VHOST appdev
SetEnv APPLICATION_ENV development
ServerName appdev
ServerAlias appdev.mywebsite.com
ServerPath /hg/software/appdev/src/public/
DocumentRoot /hg/software/appdev/src/public/
ErrorLog /hg/hgweb/logs/appdev_error.log
CustomLog /hg/hgweb/logs/appdev_access.log common
<Directory />
Options Indexes FollowSymLinks SymLinksIfOwnerMatch
AllowOverride All
Order Allow,Deny
Allow from All
</Directory>
</VirtualHost>
.htaccess:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
Any insight into what may be causing this is greatly appreciated.
GE
UPDATE
2010.06.23
I've resolved this without solving it. As drastic as it may sound, we needed a fix before the end of a week. Multiple attempts to intercept what, exactly, Apache or PHP were doing were unsuccessful. So the server was rebuilt and a different Linux distro was used. The switch from RHEL 5.5 to Ubuntu server proved successful.
If anyone feels they can comment further on this issue, it would still be appreciated. In the past several days, we were unable to replicate this issue on other server (stand-alone or virtual, Red Hat or Ubuntu.) It annoys me no end to not understand what the problem was.
GE