Question

For some reason this rule

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ ./rewrite.php?p=$1&%{QUERY_STRING} [L]

doesn’t work for URLs like this http://site.com/index/var/val
All other URLs work but this doesn’t. It starts working when I either remove !-f
part or rename index.php file located in the root to something else (e.g. test.php). So somehow site.com/index seems to be equal to site.com/index.php in the eyes of mod_rewrite? The files are located in the root so there shouldn’t be any other (upper) .htaccess files involved. This doesn’t happen to index only, for example if I create /something.xml, test.com/something/… will suddenly stop working. This happens on some servers only.

Does anyone know why this could be happening?

PS. /index directory is not present on this server

Answer 1

The faulty module is mod_negotiation, not mod_rewrite.

In debian :

a2dismod negotiation

Edit:

To be a little more specific this is the effect of Multiviews, handled by mode_negotiation. So you could keep the module and remove the MultiViews handling with:

Options -MultiViews

From documentation:

A MultiViews search is enabled by the MultiViews Options. If the server receives a request for /some/dir/foo and /some/dir/foo does not exist, then the server reads the directory looking for all files named foo.*, and effectively fakes up a type map which names all those files, assigning them the same media types and content-encodings it would have if the client had asked for one of them by name. It then chooses the best match to the client’s requirements, and returns that document.