【问题标题】:Making .htaccess more efficient使 .htaccess 更高效
【发布时间】:2020-05-12 09:25:23
【问题描述】:

我有一个 .htaccess,多年来我使用这个网站作为指南拼凑而成,但希望我可以整合一些线路以提高效率。

这些行做了三件事:

  1. 将任何非 www 请求重定向到 www 变体;
  2. 将任何 .com 请求重定向到正确的 .org TLD;
  3. 将任何 http 重定向到正确的 https 变体; 3.

这是我所拥有的:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]
RewriteEngine On
RewriteCond %{http_host} ^example.com
RewriteRule ^(.*) https://www.example.org/$1 [R=301,L]
RewriteEngine On
RewriteCond %{HTTP_HOST} example\.org [NC]
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.org/$1 [R,L]

有没有办法将这些功能中的(至少一些)组合成更少的行?

我没有任何问题,只是我的组织者觉得它可以更整洁.....

提前感谢您的任何建议!

【问题讨论】:

  • 去掉多余的RewriteEngine On,然后它看起来会很棒:规则清晰明了。即使有可能(或很容易做到)——那么结果将是混乱的 10 倍。
  • @zerkms 看起来“外表”是骗人的!

标签: apache .htaccess redirect mod-rewrite


【解决方案1】:

您无需重复写入RewriteEngine On。一次就够了。

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]

RewriteCond %{HTTP_HOST} ^example\.com
RewriteRule ^(.*)$ https://www.example.org/$1 [R=301,L]

RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

【讨论】:

  • 虽然第二条规则实际上并没有做任何事情。
  • 啊……不是吗?我得出结论(未经测试),它将建立从example.com 上的任何页面到example.org 上的对应页面的 301 重定向(?)
  • 嗯,这是因为第一条规则将所有内容重定向到www.。第二条规则只匹配example.com,所以从不匹配。您可以更改条件以匹配 www.example.com(或仅删除 ^) - 但现在您可能有 2 个重定向,无需重新排序(并且可能调整)规则。
【解决方案2】:
# 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?)

  1. 将任何 .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 指令。

简化(和“固定”):

  1. 将任何非 www 请求重定向到 www 变体;
  2. 将任何 .com 请求重定向到正确的 .org TLD;
  3. 将任何 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 文件的顶部。

【讨论】:

  • 我亲爱的@mrwhite - 我非常感谢你的帮助 - .htaccess 上的这种教育对我来说是无价的!多年来,我一直在尽我最大的努力来了解它是如何工作的,但我的脑海里一直在萦绕着我没有尽我所能(重定向的特殊功能),但我不知道我是太离谱了!感谢您花时间解释它并为我提供解决方案,我由衷地深表感激(实际上并被吹走了)。如果我有任何要孩子的计划,我会生一个并以你的名字命名他/她。干杯!!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-03-08
  • 1970-01-01
  • 1970-01-01
  • 2021-09-15
  • 2015-10-18
  • 1970-01-01
相关资源
最近更新 更多