永久重定向与 RedirectMatch,哪个更好地在 Apache 中实施 SSL 安全?

Ulu*_*kai 3 linux .htaccess apache-2.4

我一直在使用:

RedirectMatch /(.*) https://www.website.com/$1
Run Code Online (Sandbox Code Playgroud)

在 apache 中强制从虚拟主机 80 重定向到 443。

我的理由是,抓取用户输入的任何内容并将其直接转换为 https 是有意义的。然而,我也经常看到这种用法:

Redirect permanent / https://www.website.com/
Run Code Online (Sandbox Code Playgroud)

我没有使用它,因为我假设它不是用户输入的地址到 https 的精确翻译。

哪一种最适合与使用严格传输安全性一起对整个站点实施加密?

小智 6

Redirect 或 RedirectMatch 可以是 301 或 302,具体取决于您调用它的方式,因此这不是两者之间的区别。

\n\n

差异和含义:

\n\n

不同之在于Redirect仅匹配简单的 URL-PATH,而RedirectMatch允许您使用正则表达式模式匹配。

\n\n

另外,301 是永久重定向,302 是临时重定向重定向。

\n\n

寻找戈多

\n\n

为了保持搜索引擎排名,您应该始终使用 301 重定向。理想情况下,对于 SEO,您希望协议和 FQDN 具有一定的一致性,因此它远远超出了仅强制执行 SSL/TLS 的范围。

\n\n

假设您的主页的“完整”URL 是:

\n\n
https://www.example.com/index.php\n
Run Code Online (Sandbox Code Playgroud)\n\n

尽管您的服务器可能不区分大小写,并且将所有子域别名为根域,并且如果文件“index”不是隐式在路径中,则它将使用文件“index”,以便您到达相同的位置只需在浏览器的位置字段中输入\n example.com\n即可。虽然这确实使用户可以轻松直接输入,但example.com它会给搜索引擎优化带来潜在的问题。如果这就是你的服务器的设置方式所有这些 URL 都会解析为完全相同的内容:

\n\n
https://www.example.com/index.php\nhttps://www.example.com/index\nhttps://www.example.com/\nhttps://example.com/index.php\nhttps://example.com/index\nhttps://example.com/\nhttp://www.example.com/index.php\nhttp://www.example.com/index\nhttp://www.example.com/\nhttp://example.com/index.php\nhttp://example.com/index\nhttp://example.com/\n
Run Code Online (Sandbox Code Playgroud)\n\n

但是,即使您的服务器可能认为这些都是相同的,并且提供的内容也相同,Google 也会认为它们都是唯一的 URL,当他们确定这 12 个 URL 提供重复的内容时,你将在搜索排名中受到惩罚。

\n\n

仅确保所有内部链接都指定为首选 URL \xe2\x80\x94 是不够的,您网站的某些粉丝无疑会发布链接,并按照您的意愿编写http://example.com链接https://www.example.com所以你需要谷歌才能知道http://example.com应该被解释为你的首选,而做到这一点的方法是使用永久重定向。

\n\n

现在你可以制作一个Redirect或一个RedirectMatch永久 (301):

\n\n
Redirect 301 /here/ https:www.example.com/there/\nRedirectMatch 301 /here/(.*) https:www.example.com/there/$1\n
Run Code Online (Sandbox Code Playgroud)\n\n

此外,对于永久重定向,这些变体:

\n\n
Redirect 301\nRedirect Permanent\nRedirectPermanent\n
Run Code Online (Sandbox Code Playgroud)\n\n

都意味着完全相同的事情。

\n\n

玫瑰不是玫瑰不是玫瑰不是玫瑰

\n\n

我什至没有涉及目录或参数的尾部斜杠和区分大小写,但这些也有影响。Google 唯一不关心大小写或尾部斜线的情况是在根域中。

\n\n

所有这些都与谷歌相同:

\n\n
www.MyFunDomain.com/\nwww.MyFunDomain.com\nwww.myfundomain.com/\nwww.myfundomain.com\nWWW.MyFuNdOmAiN.COM\n
Run Code Online (Sandbox Code Playgroud)\n\n

这是因为域名规范规范不区分大小写。但这些:

\n\n
example.com/MyPath/\nexample.com/MyPath\nexample.com/mypath/\nexample.com/mypath\nexample.com/mYpAtH\n
Run Code Online (Sandbox Code Playgroud)\n\n

即使您的系统或服务器认为它们是相同的,它们也被认为是不同的。虽然 TLD 不需要尾部斜杠,但所有路径都需要尾部斜杠。le.com/mypath/暗示le.com/mypath/index.htmlle.com/mypath暗示le.com/mypath.html

\n\n

最佳实践

\n\n

解决这个问题的方法是:

\n\n

1)制定内部标准,所有路径和文件名只能小写

\n\n

2) 设置重写规则,对方案、子域、尾随路径斜杠和文件扩展名的所有变体进行永久 301 重定向。

\n\n

因为可能性实际上是无限的,并且Redirect需要区分大小写的路径,RedirectMatch或者Rewrite是更好的选择,因此每种可能的变化:

\n\n
https://www.example.com/sitepath/\n
Run Code Online (Sandbox Code Playgroud)\n\n

完全按照这种方式向 Google 抓取工具显示,而不是

\n\n
http://example.com/SitePath/index.php\n
Run Code Online (Sandbox Code Playgroud)\n\n

我不会发布重写规则的具体示例,因为存在太多变量(包括 HSTS 问题)和产生问题的方法。相反,我将向您推荐Dan Morell非常出色的非 HSTS站点教程以及HSTS 站点的单独链接。

\n