HSTS 预加载列表 - www 网站可能存在 SEO 问题

让我在这里解释一下现实世界的情况。

我运行网站https://www.liloo.ro https://www.liloo.ro我想为其启用 HSTS（+HSTS 预加载）。

问题是为了将其提交给预加载列表 https://hstspreload.org/ the 主域必须使用 HSTS 标头进行响应。

让我更准确地说： 为了将站点提交到预加载列表并满足第一个重定向的要求必须到主域的 https 版本。

就我而言，我无法从 http 直接重定向到 https + www -> 我必须首先从 http 重定向到 https（在此处提供主域名 HSTS 标头），然后再次重定向到 https + www

这带来了巨大的重定向稀释 SEO 问题（更不用说链式重定向并不理想）。

因此，我从各个方面来看，要么必须放弃 HSTS 预加载列表，要么使用链式重定向。这两种选择看起来都不理想。

唯一可能的解决方法可能是预加载列表要求中的某些内容，但我不太明白它的含义：

如果您提供重定向，则该重定向必须具有 HSTS 标头，而不是其重定向到的页面。

据我所知，在进行重定向时没有办法提供 HSTS 标头之类的服务......但也许我错了。 有什么想法如何解决这个问题吗？ ...或者我应该完全放弃 HSTS 预加载列表，因为我的网站只有 www？

此时我不能从 www 切换到非 www...我知道这将是“简单”的解决方案。

任何想法 - 非常感谢。 我注意到这个线程在 web.config 中重定向到 www 子域期间在域根上添加 HSTS http 标头 https://stackoverflow.com/questions/35013967/adding-hsts-http-headers-on-domain-root-during-redirect-to-www-subdomain-in-web?rq=1...但我怀疑它能解决问题（+我正在使用 nginx）

我真的很感谢你发布这个，因为我有完全相同的问题，即http://DOMAIN重定向directly to https://www.DOMAIN, 结合重定向到 HTTPSand那个一到那个www子域。

我知道这将是“简单”的解决方案。

请注意，有reasons https://serverfault.com/questions/145777/what-s-the-point-in-having-www-in-a-url使用子域，例如www，正如一直以来讨论过 https://meta.stackexchange.com/questions/45277/why-isnt-stackoverflow-using-www-in-the-url已经有好几次了，所以这个选择是完全可以理解的。

然而，HSTS 没有办法（至少目前还没有）将这两个重定向结合起来：它只能转发directly到 HTTPS。我想如果 HSTS 预加载站点检测到这是not简单的 HTTP 服务器本身所做的事情，然后强制执行“307 内部重定向”到 HTTPS 是不允许的。 （据我所知，这个要求并没有明确说明hsts预载 https://hstspreload.org，但只能通过实际尝试设置 HSTS 预加载才能找到。）

我没有完整回答你的问题，但我可以就你提出的几点提供更多信息：

如果您提供重定向，则该重定向必须具有 HSTS 标头，而不是其重定向到的页面。

请注意准确的（当前）报价hsts预载 https://hstspreload.org:

如果您正在服务额外的从您的重定向HTTPS站点，该重定向仍必须具有 HSTS 标头（而不是其重定向到的页面）。

这与以下几点相关：

据我所知，在进行重定向时没有办法提供 HSTS 标头之类的服务......

HTTP 重定向响应完全有可能also有一个 HSTS 标头。这仅意味着 HTTP 重定向响应还包含Strict-Transport-Security具有适当参数的标头字段。例如，使用 SWI-Prolog 作为 HTTP 服务器，您可以发出如下响应：

?- http_status_reply(moved('https://stackoverflow.com'), current_output,
     [strict_transport_security('max-age=63072000; includeSubdomains')], Code).
  

产量：

HTTP/1.1 301 Moved Permanently
Date: Sun, 12 Feb 2017 10:04:55 GMT
Location: https://stackoverflow.com
Strict-Transport-Security: max-age=63072000; includeSubdomains
Content-Length: 366
Content-Type: text/html; charset=UTF-8

etc.
  

请注意，此标头字段仅在 TLS 启用时才可接受already正在使用（否则，攻击者可以通过未经身份验证的连接强制流量流向不同的端口！）。事实上，标题must not发生在 HTTP→HTTPS 重定向中，因为它使用未经身份验证的连接，并且如果它（错误地）does通过纯 HTTP 发生，客户端must忽略它。

现在到你问题的实际要点：

这造成了巨大的重定向稀释搜索引擎优化问题（更不用说链式重定向并不理想）。

我完全同意链式重定向远非理想，而且对于我们这样的（常见的！）设置似乎没有办法解决这个问题，至少目前没有。

然而，我个人希望附加重定向不会对您网站的排名产生太大影响：理论上，一旦搜索引擎发现您的网站位于 HSTS 预加载列表中，它应该关心的只是它的 HTTPS 版本（因为这也是支持 HSTS 预加载的浏览器会做的事情！）。因此，您最终只会得到一个重定向，即https://DOMAIN＆右箭头;https://www.DOMAIN一个，应该与您目前的情况相当。至少这是我有点天真的希望。在此重定向中，请确保包含 HSTS 标头，因为这是进入预加载列表的要求。当然，确切的配置细节取决于您的具体 Web 服务器。

另请注意，您甚至无法恢复原始重定向链after您已将其纳入 HSTS 预加载列表。这是因为持续要求节指出：

您必须确保您的网站继续满足提交要求每时每刻.