为什么 RewriteCond %{REQUEST_FILENAME} !-d 是强制性的? [英] Why is RewriteCond %{REQUEST_FILENAME} !-d mandatory?

问题描述

为什么这个 .htaccess 在访问 example.com/mywebsite/

时有效

RewriteEngine OnRewriteCond %{REQUEST_FILENAME} !-dRewriteCond %{REQUEST_FILENAME} !-f重写规则 ^(.*)$ index.php

而这失败(404):

RewriteEngine On重写规则 ^(.*)$ index.php

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

解决方案

为了解释这种行为，我们需要对您的文件系统做出一些假设，工作"意味着提供文件(您不没有看到目录列表)...

.htaccess 文件位于文档根目录中，/mywebsite 是包含 index.php 文件(或一些 DirectoryIndex 文档).文档根目录中没有 index.php 文件.换句话说:

example.com/.htaccess我的网站/索引.php

在这种情况下，当您请求 example.com/mywebsite/ 时，会发生以下情况:

<块引用>

RewriteCond %{REQUEST_FILENAME} !-dRewriteCond %{REQUEST_FILENAME} !-f重写规则 ^(.*)$ 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 和图像)时，这是必需的.但是，如果您想通过前端控制器控制对某些物理文件(可能是下载"部分)的访问，则可以省略此指令.

Why does this .htaccess work when accessing example.com/mywebsite/

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

whereas this fails (404):

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

I thought the second solution should work as well.

解决方案

In order to explain this behaviour, we need to make some assumptions about your file system, and by "work" you mean that a file is served (you don't see a directory listing)...

The .htaccess file is located in the document root and /mywebsite is a physical directory that contains an index.php file (or some DirectoryIndex document). There is no index.php file in the document root. In other words:

example.com/
    .htaccess
    mywebsite/
        index.php

In this scenario, when you request example.com/mywebsite/ the following happens:

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

/mywebsite/ is a physical directory, so the first condition fails and the RewriteRule is not processed.

mod_dir then searches for a DirectoryIndex, finds index.php and the .htaccess file is reprocessed. This now maps to a physical file, so the second condition fails and the RewriteRule is not processed.

The net result is that example.com/mywebsite/index.php gets requested. The same as if there was no .htaccess file at all.

RewriteRule ^(.*)$ index.php

However, in this scenario, there are no conditions. The RewriteRule gets processed unconditionally and internally rewrites the request to example.com/index.php (strictly speaking it's <filesystem-path-to-document-root>/index.php) since that is where the .htaccess file is located.

However, there is no index.php file in the document root; hence the 404.

Why is RewriteCond %{REQUEST_FILENAME} !-d mandatory?

Whether it is mandatory or not is really dependent on your filesystem and what you are trying to do. But generally, you don't normally want physical directories to be processed by the front controller.

The !-f condition is usually more important since you often don't want physical files to be processed by the front controller. This is required when you want to serve static resources (eg. CSS, JavaScript and images) from the same area on the filesystem. However, you might omit this directive if you wanted to control access to some physical files (perhaps a "download" section) through the front controller.

这篇关于为什么 RewriteCond %{REQUEST_FILENAME} !-d 是强制性的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！