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

【问题标题】：Why is RewriteCond %{REQUEST_FILENAME} !-d mandatory?为什么 RewriteCond %{REQUEST_FILENAME} !-d 是强制性的？
【发布时间】：2023-03-18 01:41:01
【问题描述】：

为什么这个.htaccess在访问example.com/mywebsite/时会起作用

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

而这失败了（404）：

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

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

【问题讨论】：

第二种“解决方案”会导致无限的重写循环。
@arkascha 这不应该导致重写循环，除非您在替换中使用捕获的组，例如。 index.php/$1。事实上，如果第一个有效，那么第二个也应该有效。
您在/mywebsite 子目录中有另一个.htaccess 文件吗？ - 假设这是一个真正的子目录？
@w3dk: 不，我没有其他 .htaccess

标签： apache .htaccess mod-rewrite

【解决方案1】：

为了解释这种行为，我们需要对您的文件系统做出一些假设，“工作”是指提供文件（您看不到目录列表）...

.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 和图像）时，这是必需的。但是，如果您想通过前端控制器控制对某些物理文件（可能是“下载”部分）的访问，则可以省略此指令。

【讨论】：

感谢您提供如此详细的答案！唯一的区别是我的 .htaccess 在 mywebsite/ 内，就在 index.php 旁边。
在这种情况下，没有其他文件和其他指令，两者都应该“工作”。好吧，第一个规则块实际上不会做任何事情（出于与上述相同的原因），您最终只是直接请求index.php（就像没有.htaccess 文件一样）。如果没有上述条件，则无论如何都会将请求重写到相同的index.php 文件。您不应该在这里收到 404，除非 index.php 本身触发了它 - 但这并没有真正意义，因为请求几乎相同。