为什么RewriteCond％{REQUEST_FILENAME}！-d是强制性的？

Question

访问example.com/mywebsite/

时，为什么此RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php 有效

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

然而这失败了（404）：

{{1}}

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

Answer 1

为了解释这种行为，我们需要对你的文件系统做一些假设，并通过＆＃34; work＆＃34;你的意思是提供了一个文件（你没有看到目录列表）......

.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然后搜索DirectoryIndex，找到index.php并重新处理.htaccess文件。现在，这将映射到物理文件，因此第二个条件失败，并且未处理RewriteRule。

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

RewriteRule ^(.*)$ index.php

但是，在这种情况下，没有条件。 RewriteRule无条件处理，在内部重写请求example.com/index.php（严格来说就是<filesystem-path-to-document-root>/index.php），因为那是.htaccess找到文件。

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

  

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

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

!-f条件通常更重要，因为您通常不希望前端控制器处理物理文件。当您想要从文件系统的同一区域提供静态资源（例如CSS，JavaScript和图像）时，这是必需的。但是，如果要通过前端控制器控制对某些物理文件（可能是＃34; download＆＃34;部分）的访问，则可以省略此指令。