Question

我有一个非常简单的.htaccess文件，用于将任何请求重定向到index.php，如果该文件不存在且不是目录。

[建议的修改前]

<IfModule mod_rewrite.c>
RewriteEngine On

#REWRITE RULES
#---------------------

#RULE COMPLETEREWRITE
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.* index.php

</IfModule>

[建议修改后]

<IfModule mod_rewrite.c>
RewriteEngine On

#REWRITE RULES
#---------------------

#RULE COMPLETEREWRITE
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.*$ index.php [L]

</IfModule>

（htaccess修改之间没有变化）

目前，无论文件是否存在，它都会重定向到index.php。任何人都可以解释为什么会这样吗？

这似乎是一个愚蠢的问题 - 但我已经做了一些研究并且发现很少。

这是在Ubuntu的Apache 2.4下运行，启用了mod_rewrite，显然我希望。

案例场景：

'/resource/img/panoramas/1.png'中的文件存在。通过本地文件浏览器，SSH和FTP验证我的VM文件系统。

在实施htaccess文件之前，可以远程访问此文件。我有一个缓存版本来证明它。

实现htaccess文件后，任何尝试命中此路径都会返回index.php。

===============

我的CMS的核心包含在使用重写时创建标头的方法。如果我登陆index.php本身，我不会标记重写（如预期的那样）。如果我点击此目录下的任何其他路径，我最终会在index.php上带有重写标志（部分预期）。如果文件存在，则情况不应该如此，但仍然与预期相反。

也可能需要注意，此htaccess文件是从web.config（IIS）文件自动生成的，而在IIS下，这些规则和我的CMS都完全按预期工作。

最后（与最佳实践相反），整个目录被chmod到777，以消除文件无法访问的可能性。

Answer 1

试试这个：

  <Component Id="Xceed.Wpf.AvalonDock.dll" Guid="{3E99B3EA-8528-4125-A8BA-B492B341479C}">
    <File Id="Xceed.Wpf.AvalonDock.dll" Name="Xceed.Wpf.AvalonDock.dll" Source="$(var.project.TargetDir)Xceed.Wpf.AvalonDock.dll" KeyPath="yes" DiskId="1" />
  </Component>
......
  <Component Id="Xceed.Wpf.Toolkit.dll" Guid="{A9809E88-A097-4FFF-B311-8CB49B1B2FC5}">
    <File Id="Xceed.Wpf.Toolkit.dll" Name="Xceed.Wpf.Toolkit.dll" Source="$(var.project.TargetDir)Xceed.Wpf.Toolkit.dll" KeyPath="yes" DiskId="1" />
  </Component>

这是一个疯狂的猜测。如果我们要提供更多的猜测，你应该启用日志记录并发布日志，因为可能出错的事物的表面很大;）

RewriteEngine On

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f 
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
RewriteRule ^.* index.php

Answer 2

您可以尝试对文件/目录进行替代检查：

RewriteEngine On

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-l
RewriteRule ^ index.php [L]

在正常情况下%{DOCUMENT_ROOT}%{REQUEST_URI}解析为与%{REQUEST_FILENAME}相同的完整文件系统路径，但在您的情况下，%{REQUEST_FILENAME}未得到解决。

Answer 3

如果文件/页面不存在，您可以使用404 Error方式将用户重定向到index。

如下：

ErrorDocument 404 /index.php

Answer 4

这很不寻常，显然不是预期的结果。因此，可以安全地假设问题可能是另一个.htaccess文件干扰了您的重写。或者，您可以在另一个执行此操作的Apache配置文件中有一个指令。

为了追踪问题的根本原因，您需要告诉Apache记录/跟踪重写。在运行Apache 2.4时，您需要为虚拟主机设置LogLevel，如下所示：

LogLevel warn mod_rewrite.c:trace4 # where trace<n> is the level of tracing

_{（旁注：Apache的早期版本使用了RewriteLog，但现在在最新的Apache 2.4中已弃用。）}

然后，您可以访问您网站的日志，在某处您应该看到以下内容：

[Tue Jun 16 16:51:40.123993 2015] [rewrite:trace4] [pid 5412:tid 1680] mod_rewrite.c(475): [client <client_ip_port>] <ip> - - [<your_domain>/sid#1406168][rid#1cb2150/initial] [perdir <document_root>] RewriteCond: input='<document_root>' pattern='!-f' => matched
[Tue Jun 16 16:51:40.123993 2015] [rewrite:trace4] [pid 5412:tid 1680] mod_rewrite.c(475): [client <client_ip_port>] <ip> - - [<your_domain>/sid#1406168][rid#1cb2150/initial] [perdir <document_root>] RewriteCond: input='<document_root>' pattern='!-d' => not-matched

如果您没有看到这些行（特别是第一行），则可能意味着该文件确实不存在。如果该线存在，那么我担心其他因素导致问题。尽管如此，使用跟踪器可以帮助您识别问题，以便您可以轻松解决它。

Answer 5

也许是因为你抓住所有东西并将它发送到RewriteRule中的index.php试试这个：

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

为什么这个.htaccess文件没有呈现存在的文件？

5 个答案: