htaccess RewriteCond REQUEST_URI 检测不起作用答案

【问题标题】：htaccess RewriteCond REQUEST_URI detection not workinghtaccess RewriteCond REQUEST_URI 检测不起作用
【发布时间】：2013-08-09 04:03:58
【问题描述】：

对于两种不同类型的 URI，我有两件不同的事情想要发生，但我似乎无法阻止第二种情况在第一种情况已被接受的情况下执行。

这是一个例子：

abc.com
abc.com/asdf
abc.com/en/asdf
abc.com/zh-cn/asdf/asdf

都应该指向这个 RewriteRule：

RewriteRule ^(([a-z]{2})(-[a-z]{2})?)(/([a-z0-9-\./]*))?$ /index.php?lng=$1&tpl=$4 [QSA,L,NC]

第 2 部分：

abc.com/myadmin/
abc.com/myadmin/asdf
abc.com/myadmin/en/asdf
abc.com/myadmin/zh-cn/asdf/asdf

都应该指向这个 RewriteRule：

RewriteRule ^myadmin/(([a-z]{2})(-[a-z]{2})?)(/([a-z0-9-\./]*))?$ /myadmin/index.php?lng=$1&tpl=$4 [QSA,L,NC]

我一直试图实现这一点的方法是通过堆叠这样的条件：

RewriteCond %{REQUEST_URI} !^/myadmin/
RewriteRule ^(([a-z]{2})(-[a-z]{2})?)(/([a-z0-9-\./]*))?$ /index.php?lng=$1&tpl=$4 [QSA,L,NC]

RewriteCond %{REQUEST_URI} ^/myadmin/
RewriteRule ^myadmin/(([a-z]{2})(-[a-z]{2})?)(/([a-z0-9-\./]*))?$ /myadmin/index.php?vlng=$1&tpl=$4 [QSA,L,NC]

但无论我做什么，两条规则仍然执行。也许我做对了，二级执行在 php 模板中发生得更远，我不确定。我只需要知道到目前为止我所做的一切是否看起来不错。

【问题讨论】：

标签： .htaccess mod-rewrite

【解决方案1】：

替换这个条件：

RewriteCond %{REQUEST_URI} !^/myadmin/

有了这两个：

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

把它们放在一起：

Options +FollowSymLinks -MultiViews
# Turn mod_rewrite on
RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule ^myadmin/(([a-z]{2})(-[a-z]{2})?)(/([a-z0-9-\./]*))?$ /myadmin/index.php?vlng=$1&tpl=$4 [QSA,L,NC]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule ^(([a-z]{2})(-[a-z]{2})?)(/([a-z0-9-\./]*))?$ /index.php?lng=$1&tpl=$4 [QSA,L,NC]

【讨论】：

这似乎不能解决我的问题，即使我一起删除第二组条件并将我的 URI 硬编码到 /myadmin/ 目录，它仍然会调用我的 /index.php 文件服务器的根目录。您的示例中的 RewriteBase / 关键是否正常运行？我以前似乎从未需要它。
首先你必须确保上面的 .htaccess 直接在 DOCUMENT_ROOT 下。请在您的问题中转储您的完整 .htaccess 并告诉我此代码对哪个 URI 不起作用，以便我也可以从头开始测试。
完整的 .htaccess 文件将近 260 行，位于 DOCUMENT_ROOT 中。如果我在尝试访问我的管理区域时使用您上面建议的代码，则另一个 RewriteRule 也会被执行，我可以知道，因为另一个规则指向更新在我的站点公共端找到的 cookie 的代码。我可以阻止我的 cookie 更新的唯一方法是删除您在上面发布的代码的第二部分，它破坏了我网站的公共方面。我需要另一种方法来做到这一点，它不会允许两个条件都执行。
那么你的设置有些不对劲。由于/index.php 应该是一个有效文件，这将使RewriteCond %{REQUEST_FILENAME} !-f 失败并跳过第二条规则的执行。

【解决方案2】：

好的，我发现了问题，部分原因是我假设 我的 Chrome 浏览器中的清除缓存扩展程序 一次只能在一个选项卡上工作，并且该扩展程序中的默认设置 在扩展程序激活后自动重新加载所有选项卡。

与大多数开发人员一样，我在任何特定时刻都会在浏览器中打开 5 到 10 个选项卡，以访问我网站的测试区域、开发工具和技术资源。当我处理代码时，我通常会亲自手动完成所有缓存清理，以便我知道它确实完成了，在这种情况下，我选择在我的 Chrome 浏览器中添加一个名为“Clear Cache”的新扩展来帮助我解决这个问题快一点，因为我做了很多小改动，每次都需要进行干净的测试。我没有意识到的是，当您激活扩展程序时，它还会清除所有其他选项卡的缓存。我也没有注意到设置为在执行清洁后自动重新加载它们的默认设置。因为它也没有向您显示它正在重新加载所有其他选项卡，所以我不知道它正在重新加载一个选项卡，该选项卡是我打开到我正在处理的负责加载 cookie 的网站的主页。

总结一下，当我在我的网站上工作时，在一个选项卡中测试对我的管理区域的更改，我一直看到只能来自我网站的公共方面的 cookie 更新，这让我一直认为还有一些问题我的 htaccess 更改。我意识到，经过两天的故障排除后，我添加的方便的花花公子扩展程序实际上是在不让我知道的情况下重新加载浏览器中的所有选项卡，并且所有其他调用负责持续返回可能的 cookie只能由我的网站的公共方面生成，这让我很困惑。之后我将再次手动清除缓存。

【讨论】：