带有否定正则表达式条件的 .htaccess 中的 RewriteCond 不起作用? [英] RewriteCond in .htaccess with negated regex condition doesn't work?

查看:43
本文介绍了带有否定正则表达式条件的 .htaccess 中的 RewriteCond 不起作用?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在这种情况下,我试图阻止 WordPress 重写某些 URL.在这种情况下,我试图阻止它处理上传目录中的请求,而是将它们留给服务器的 404 页面.所以我假设它就像添加规则一样简单:

I'm trying to prevent, in this case WordPress, from rewriting certain URLs. In this case I'm trying to prevent it from ever handling a request in the uploads directory, and instead leave those to the server's 404 page. So I'm assuming it's as simple as adding the rule:

RewriteCond %{REQUEST_URI} !^/wp-content/uploads/

此规则应评估为 false,并使这些请求的规则链失败,从而停止重写.但是不...也许我需要匹配我表达式中的完整字符串?

This rule should evaluate to false and make the chain of rules fail for those requests, thus stopping the rewrite. But no... Perhaps I need to match the cover the full string in my expression?

RewriteCond %{REQUEST_URI} !^/wp-content/uploads/.*$

不,也不是那样.因此,在挠头之后,我检查了自己的理智.也许实际模式有问题.所以我做了一个简单的测试用例.

Nope, that's not it either. So after scratching my head I do a check of sanity. Perhaps something is wrong with the actual pattern. So I make a simple test case.

RewriteCond %{REQUEST_URI} ^/xyz/$

在这种情况下,当且仅当请求的 URL 是/xyz/并且为任何其他页面显示服务器的 404 页面时,才会发生重写.这正是我所期望的.所以我会坚持下去!否定这种模式.

In this case, the rewrite happens if and only if the requested URL is /xyz/ and shows the server's 404 page for any other page. This is exactly what I expected. So I'll just stick in a ! to negate that pattern.

RewriteCond %{REQUEST_URI} !^/xyz/$

现在我期待看到与上述情况完全相反的情况.重写不应该发生在/xyz/上,而是发生在所有其他可能的 URL 上.相反,重写会针对每个 URL,包括/xyz/和其他 URL.

Now I'm expecting to see the exact opposite of the above condition. The rewrite should not happen for /xyz/ but for every other possible URL. Instead, the rewrite happens for every URL, both /xyz/ and others.

因此,要么在 RewriteConds 中使用否定的正则表达式在 Apache 中被破坏,要么有一些我不了解的基本原理.是哪个?

So, either the use of negated regexes in RewriteConds is broken in Apache, or there's something fundamental I don't understand about it. Which one is it?

服务器是Apache2.

The server is Apache2.

整个文件:

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteBase /
RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/wp-content/uploads/
RewriteRule . /index.php [L]
</IfModule>

WordPress 的默认文件加上我的规则.

WordPress's default file plus my rule.

推荐答案

所以,在经历了很多恼火之后,我终于找到了问题所在.事实证明,我最初问题中的规则实际上完全符合它的预期.做同样事情的许多其他方法也是如此,例如

So, after a lot of irritation, I figured out the problem, sort of. As it turned out, the rule in my original question actually did exactly what it was supposed to. So did a number of other ways of doing the same thing, such as

RewriteRule ^wp-content/uploads/.*$ - [L]

(如果模式匹配,则将规则标记为最后)或

(Mark rule as last if pattern matches) or

RewriteRule ^wp-content/uploads/.*$ - [S=1]

(如果模式匹配,则跳过下一条规则)以及问题中的否定规则,如上所述.所有这些规则都运行良好,无需重写即可将控制权返回给 Apache.

(Skip the next rule if pattern matches) as well as the negated rule in the question, as mentioned. All of those rules worked just fine, and returned control to Apache without rewriting.

处理这些规则后出现问题.相反,问题是我删除了我的主机提供的默认 404.shtml、403.shtml 等模板.如果你没有任何 .htaccess 重写,那工作得很好;服务器将提供自己的默认 404 页面,一切正常.(至少我是这么想的,但实际上这是双重错误另外,在尝试使用 ErrorDocument 处理请求时遇到了 404 Not Found 错误.")

The problem happened after those rules were processed. Instead, the problem was that I deleted a the default 404.shtml, 403.shtml etc templates that my host provided. If you don't have any .htaccess rewrites, that works just fine; the server will dish up its own default 404 page and everything works. (At least that's what I thought, but in actual fact it was the double error "Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.")

另一方面,当您确实拥有 .htaccess 时,它会为 404 页面第二次执行.如果页面在那里,它将被使用,但现在,对 404.shtml 的请求被捕获所有规则捕获并重写到 index.php.出于这个原因,我在这里或其他地方得到的所有其他建议都失败了,因为最终 404 页面已被重写为 index.php.

When you do have a .htaccess, on the other hand, it is executed a second time for the 404 page. If the page is there, it will be used, but now, instead the request for 404.shtml was caught by the catch-all rule and rewritten to index.php. For this reason, all other suggestions I've gotten here, or elsewhere, have all failed because in the end the 404 page has been rewritten to index.php.

因此,解决方案只是恢复错误模板.回想起来,删除它们是非常愚蠢的,但我有这种从头开始"的心态.不希望任何看似不必要的东西散布.至少现在我明白发生了什么,这就是我想要的.

So, the solution was simply to restore the error templates. In retrospect it was pretty stupid to delete them, but I have this "start from scratch" mentality. Don't want anything seemingly unnecessary lying around. At least now I understand what was going on, which is what I wanted.

最后对 Cecil 发表评论:我从来不想禁止访问任何东西,只是阻止重写发生.现在不是很重要,但我只是想澄清一下.

Finally a comment to Cecil: I never wanted to forbid access to anything, just stop the rewrite from taking place. Not that it matters much now, but I just wanted to clarify this.

这篇关于带有否定正则表达式条件的 .htaccess 中的 RewriteCond 不起作用?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆