我真的很感谢你发布了这个,因为我有完全相同的问题,即直接http://DOMAIN
重定向到,结合重定向到 HTTPS和一个到 子域。https://www.DOMAIN
www
我知道这将是“简单”的解决方案。
请注意,使用类似 的子域是有原因www
的,正如已经多次讨论过的那样,因此这种选择是完全可以理解的。
但是,HSTS 没有办法(至少目前还没有)将这两种重定向结合起来:它只能直接转发到 HTTPS。我想如果 HSTS 预加载站点检测到这不是普通 HTTP 服务器本身所做的,那么将“307 内部重定向”强制执行为仅 HTTPS 是不可接受的。(据我所知,这个要求并没有在hstspreload.org上明确说明,但只能通过实际尝试设置 HSTS 预加载来发现。)
对于您的问题,我没有完整的答案,但我可以就您提出的几点提供更多信息:
如果您正在提供重定向,则该重定向必须具有 HSTS 标头,而不是它重定向到的页面。
请注意hstspreload.org的准确(当前)报价:
如果您从HTTPS 站点提供额外的重定向,则该重定向必须仍然具有 HSTS 标头(而不是它重定向到的页面)。
这与以下几点有关:
据我所知,在进行重定向时没有办法提供 HSTS 标头之类的东西......
HTTP 重定向响应也完全有可能具有 HSTS 标头。这仅意味着 HTTP 重定向响应还包含Strict-Transport-Security
带有合适参数的标头字段。例如,使用 SWI-Prolog 作为 HTTP 服务器,您可以发出这样的响应:
?- http_status_reply(moved('https://stackoverflow.com'), current_output,
[strict_transport_security('max-age=63072000; includeSubdomains')] , 代码)。
产生:
HTTP/1.1 301 永久移动
日期:2017 年 2 月 12 日星期日 10:04:55 GMT
位置:https://stackoverflow.com
严格的传输安全性:max-age=63072000;包括子域
内容长度:366
内容类型:文本/html;字符集=UTF-8
等等
请注意,此标头字段仅在已使用TLS 时才允许使用(否则,攻击者可能会通过未经过身份验证的连接将流量强制到不同的端口!)。事实上,标头不能出现在 HTTP→HTTPS 重定向中,因为它使用未经身份验证的连接,如果它(错误地)确实出现在普通 HTTP 上,客户端必须忽略它。
现在到您问题的实际要点:
这带来了巨大的重定向稀释SEO 问题(更不用说链式重定向并不理想的事实)。
我完全同意链式重定向远非理想,而且似乎没有办法像我们这样(常见!)设置解决这个问题,至少目前不是。
但是,我个人希望额外重定向的影响不会对您网站的排名产生太大影响:理论上,一旦搜索引擎看到您的网站在 HSTS 预加载列表中,它应该关心的是它的 HTTPS 版本(因为这也是支持 HSTS 预加载的浏览器会做的事情!)。因此,您最终只有一个重定向,即https://DOMAIN
→https://www.DOMAIN
一个,它应该与您当前的情况相当。至少这是我有些天真的希望。在此重定向中,请确保包含 HSTS 标头,因为这是进入预加载列表的要求。当然,确切的配置细节取决于您的具体 Web 服务器。
另外,请注意,即使您已将其放入 HSTS 预加载列表,也无法恢复原始重定向链。这是因为“持续要求”部分指出:
您必须确保您的网站始终满足提交要求。