# Rule #1
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]
# Rule #2
RewriteCond %{http_host} ^example.com
RewriteRule ^(.*) https://www.example.org/$1 [R=301,L]
# Rule #3
RewriteCond %{HTTP_HOST} example\.org [NC]
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.org/$1 [R,L]
是的,您的规则可以优化。尤其是因为他们实际上并没有按照你说的去做!
(我假设您无意实施HSTS?)
- 将任何 .com 请求重定向到正确的 .org TLD;
这些指令实际上并未将.com 变体重定向到.org,正如您在第二个要求中所建议的那样。如果您看到此重定向,则不是因为这些指令。很可能 WordPress 本身正在执行此操作,稍后在请求中。
例如...
场景 #1:
- 请求
http://www.example.com/(或https://www.example.com/)
- 由于请求的主机与 rule #1、#2 或 #3 不匹配,因此不会发生重定向
- 请求未重定向到
.org(如果请求到 http://...,则未重定向到 HTTPS)
场景 #2:
- 请求
http://example.com/(或https://example.com/)
- 通过规则#1重定向到
https://www.example.com/(同一域)
- 如上文“场景 #1”所述,不会发生进一步的重定向。
- 请求未重定向到
.org。
从这些示例中您可以看到,您的 规则 #2(仅匹配 example.com)实际上并没有做任何事情。它总是绕过,因为rule #1 已经将请求重定向到www 子域。如果 rule #1 和 #2 颠倒过来会“更好”,但是,当请求 www.example.com(www 子域)时,这仍然无法解决问题,因为什么都不会发生。
其他说明:
-
规则 #3 - HTTP 到 HTTPS 重定向 - 是临时 (302) 重定向。这应该是 301,就像其他人一样。
- 无需重复
RewriteEngine On 指令。它只需要在文件中出现一次。 (当.htaccess 文件是由“机器”而不是“手工”编辑时,经常看到重复。)为了便于阅读,这应该在文件的顶部。但是,如果您有多个 RewriteEngine 指令,则实际上是 last 实例赢得并控制整个文件(这可能不直观)。例如。如果您在 .htaccess 文件的最后放置一个 RewriteEngine Off 指令,那么……它对整个文件都关闭,尽管您可能在此之前有任何 RewriteEngine 指令。
简化(和“固定”):
- 将任何非 www 请求重定向到 www 变体;
- 将任何 .com 请求重定向到正确的 .org TLD;
- 将任何 http 重定向到正确的 https 变体; 3
只有当所有内容都重定向到 www + .org + HTTPS 时,这 3 个要求才能满足。 IE。一切都必须重定向到https://www.example.org/(规范网址)。
因此,您现有的 3 条规则可以简化为一条规则,以满足您的 3 条要求。 IE。如果请求不是针对https://www.example.org/,则重定向到https://www.example.org/。
RewriteEngine On
# If not the canonical host OR not HTTPS then redirect to HTTPS + canonical host
RewriteCond %{HTTP_HOST} !^www\.example\.org$ [OR]
RewriteCond %{SERVER_PORT} 80
RewriteRule (.*) https://www.example.org/$1 [R=301,L]
这里我们根本不需要引用example.com,因为我们只关心它是否不是规范主机。
而且,由于这是一个 WordPress 网站,因此此重定向必须位于 WP 前端控制器之前,靠近您的 .htaccess 文件的顶部。