为什么RewriteCond%{REQUEST_FILENAME}!-d是强制性的？

为什么这.htaccess在访问时有效example.com/mywebsite/

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php

而这失败了(404):

RewriteEngine On
RewriteRule ^(.*)$ index.php

我认为第二种解决方案也应该有效.

为了解释这种行为,我们需要对你的文件系统做一些假设,而"工作"你的意思是提供一个文件(你没有看到目录列表)......

该.htaccess文件位于文档根/mywebsite目录中,是包含index.php文件(或某个DirectoryIndex文档)的物理目录.index.php文档根目录中没有文件.换一种说法:

example.com/
    .htaccess
    mywebsite/
        index.php

在这种情况下,当您请求example.com/mywebsite/以下情况时:

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php

/mywebsite/是一个物理目录,因此第一个条件失败,并且RewriteRule未处理.

mod_dir然后搜索a DirectoryIndex,查找index.php并.htaccess重新处理文件.现在,这将映射到物理文件,因此第二个条件失败,并且RewriteRule未处理.

最终结果是example.com/mywebsite/index.php获得请求.就好像根本没有.htaccess文件一样.

RewriteRule ^(.*)$ index.php

但是,在这种情况下,没有条件.在RewriteRule被无条件处理,并在内部重写请求example.com/index.php(严格来说,它是/index.php),因为这是该.htaccess文件的位置.

但是,index.php文档根目录中没有文件; 因此404.

为何RewriteCond %{REQUEST_FILENAME} !-d必须？

它是否是强制性的,实际上取决于您的文件系统以及您要执行的操作.但通常,您通常不希望前端控制器处理物理目录.

这种!-f情况通常更为重要,因为您通常不希望前端控制器处理物理文件.当您想要从文件系统的同一区域提供静态资源(例如CSS,JavaScript和图像)时,这是必需的.但是,如果要通过前端控制器控制对某些物理文件(可能是"下载"部分)的访问,则可以省略此指令.