每当一个不存在的文件试图被访问(我正在使用我的多站点网络的子文件夹配置),它创建一个500错误,并在Apache日志中导致以下错误“由于可能的配置错误,请求超过了10个内部重定向的限制。"
我使用的是WordPress提供的标准.htaccess
代码(见下文)。不使用任何自定义代码/规则
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress
例如,如果我去/blahblah/
或/blahblah/1.jpg
我得到一个404未找到错误页面-一切正常。
然而,如果我转到/blahblah/wp-content/uploads/sites/1/1.jpg
,我会得到一个500错误,它似乎会触发某种重定向循环,最终导致Apache核心错误。这似乎只发生在试图访问已删除站点中的资产时。
2条答案
按热度按时间6tqwzwtp1#
如果您请求
/blahblah/wp-content/uploads/sites/1/1.jpg
,则上述规则将请求重写为wp-content/uploads/sites/1/1.jpg
,重写引擎重新开始。这里的潜在问题是,如果/wp-content/uploads/sites/1/1.jpg
不存在,那么这个规则会再次匹配,并将请求重写为wp-content/uploads/sites/1/1.jpg
* 再次 *。(If文件确实存在,则前面的规则将阻止进一步处理,并且不发生额外的重写。
通常在Apache上,如果一个URL未经更改地通过,则处理停止。然而,这不是必须依赖的东西,因为它容易出错(不同的配置等)。如果由于某种原因没有发生,那么相同的重写将重复发生,导致对同一个不存在的文件的重写循环(以及500内部服务器错误响应)。
我怀疑这就是这里发生的事情。
但是,在WordPress上,不建议手动编辑
# BEGIN WordPress
和# END WordPress
注解标记之间的指令,因为WordPress本身会尝试管理此部分。但是,您可以在文件的顶部添加一个额外的规则(before the# BEGIN WordPress
comment marker),以避免这样的重写循环。举例来说:
您不需要重复
RewriteEngine
指令,该指令已经在文件的后面(在WordPress代码块中)出现。这将允许任何没有Map到物理文件的
/wp-content/uploads/sites/1/1.jpg
形式的(重写)请求简单地落入Apache生成的“404 Not Found”响应。鉴于上述情况,还可以为
.php
URL添加一个例外(根据上面讨论的规则重写),如果它们不Map到物理文件,也可能遭受同样的命运。因此,在上面添加的规则之后,在文件的顶部 before WordPress代码块:或者,如果你要编辑WordPress代码块,你可以在最后3个规则上使用
END
标志(而不是L
)。这是一个Apache 2.4标志,用于防止重写引擎进行任何进一步的处理。(所编写的WordPress代码块旨在在Apache 2.2或更早版本上工作。在Apache日志中,“由于可能的配置错误,请求超过了10个内部重定向的限制。”
您可以在服务器配置中临时增加
LogLevel
(Apache 2.4+),以查看重写循环的确切性质。举例来说:wko9yo5t2#
试试下面的代码