每当尝试访问不存在的文件时(我正在为我的多站点网络使用子文件夹配置),它会创建 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 核心错误。这种情况似乎仅在尝试访问已删除站点中的资产时才会发生。
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
如果您请求
/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
again。
(如果文件确实存在,则前面的规则将阻止进一步处理,并且不会发生额外的重写。)
通常在 Apache 上,如果 URL 未更改地通过,则处理停止。然而,这并不是必须依赖的东西,因为它很容易出错(不同的配置等)。如果由于某种原因没有发生这种情况,那么相同的重写将重复发生,导致重写循环到同一个不存在的文件(500内部服务器错误)。
我怀疑这就是这里发生的事情。
但是,在 WordPress 上,不建议手动编辑
# BEGIN WordPress
和 # END WordPress
注释标记之间的指令,因为 WordPress 本身会尝试管理此部分。但是,您可以在文件顶部添加一条附加规则(before # BEGIN WordPress
注释标记)以避免此类重写循环。
例如:
# Prevent further processing if "/wp-content" and related URLs are requested
RewriteRule ^wp-(content|admin|includes) - [L]
# BEGIN WordPress
:
您无需重复
RewriteEngine
指令,该指令已在文件后面(在 WordPress 代码块中)出现。
或者,如果您要编辑 WordPress 代码块,您可以在最后 3 条规则中使用
END
标志(而不是 L
)。这是一个 Apache 2.4 标志,可防止重写引擎进行任何进一步处理。 (所编写的 WordPress 代码块旨在适用于 Apache 2.2 以及可能更早的版本。)
在 Apache 日志中“由于可能的配置错误,请求超出了 10 个内部重定向的限制。”
LogLevel
(Apache 2.4+) 以查看重写循环的确切性质。例如:
LogLevel rewrite:trace5