HSTS预加载列表-www站点可能存在SEO问题 [英] HSTS preload list - possible SEO issue for www sites

查看:123
本文介绍了HSTS预加载列表-www站点可能存在SEO问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

让我在这里解释一个现实世界的情况.

Let me explain a real world situation here.

我运行网站 https://www.liloo.ro ,我想启用HSTS(+ HSTS预加载).

I run the website https://www.liloo.ro and I want to enable HSTS (+HSTS preload) for it.

问题在于,为了将其提交到主域中的预加载列表 >必须使用HSTS标头进行响应.

The problem is that in order to submit it to the preload list the main domain has to respond with a HSTS header.

让我更加精确: 为了将网站提交到预加载列表并满足要求,必须将第一个重定向重定向到主域的https版本.

Let me be more precise: In order to submit a site to the preload list and meet the requirements the first redirect has to be to the https version of the main domain.

在我的情况下,我无法从http直接重定向到https + www->我必须先从http重定向到https(在此处提供主域名HSTS标头),然后再次重定向到https + www

In my case I can't redirect from http directly to https + www -> I have to redirect first from http to https (serve the main domain name HSTS header here) and redirect once again to https + www

这带来了巨大的重定向稀释SEO问题(更不用说链式重定向不理想的事实了.)

This poses a huge redirect dilution SEO problem (not to mention the fact that chained redirects are not ideal).

因此,从每种角度看,我要么不得不放弃HSTS预载列表,要么使用链接重定向.两种选择都不理想.

So each way I look at this I either have to give up on HSTS preload list or use chained redirects. Neither option looks ideal.

唯一可能的解决方法可能是预加载列表要求中的某些内容,但我不太清楚这意味着什么:

The only possible workaround might be something from the preload list requirements but I don't quite understand what it means:

如果要提供重定向,则该重定向必须具有HSTS标头,而不是重定向到的页面.

If you are serving a redirect, that redirect must have the HSTS header, not the page it redirects to.

据我所知,在进行重定向时无法将诸如HSTS标头之类的东西提供服务……但也许我错了. 任何想法如何解决这个问题? ...还是因为我的网站仅是www而应该完全放弃HSTS预载列表?

As far as I know there is no way to serve such thing as a HSTS header when doing a redirect ... but maybe I'm wrong. Any ideas how to solve this issue? ... or should I give up on HSTS preload list altogether because my site is www only?

这时我不能只从www切换到非www ...我知道那将是简单"的解决方案.

I can't just switch from www to non-www at this point... I know it would have been the "easy" solution.

任何想法-非常感谢. 我注意到这个线程 在重定向到web.config中的www子域的过程中,在域根上添加HSTS http标头 ...但我怀疑它能否解决问题(+我正在使用nginx)

Any idea - much appreciated. I noticed this thread Adding HSTS http headers on domain root during redirect to www subdomain in web.config ...but I doubt it solves the issue (+ I'm using nginx)

推荐答案

非常感谢您发布此消息,因为我有完全相同的问题,即http://DOMAIN直接将重定向组合到HTTPS 的重定向,www 子域的.

I am really thankful you posted this, because I have exactly the same issue, i.e., http://DOMAIN redirects directly to https://www.DOMAIN, combining the redirect to HTTPS and the one to the www subdomain.

我知道那将是简单"的解决方案.

I know it would have been the "easy" solution.

请注意,存在原因使用www之类的子域,如已讨论过已经有好几次了,所以这种选择是完全可以理解的.

Note that there are reasons to use a subdomain like www, as has been discussed on several occasions already, and so this choice is completely understandable.

但是,HSTS无法(至少尚未)组合两个重定向:它只能将直接转发到HTTPS.我想如果HSTS预加载站点检测到这不是普通HTTP服务器本身所做的事,那么不允许对HTTPS强制执行"307内部重定向". (据我所知,此要求未在 hstspreload.org 中明确说明,但只能由实际上试图设置HSTS的预加载.)

However, HSTS has no way (at least not yet) to combine the two redirects: It can only forward directly to HTTPS. I suppose that if the HSTS preload site detects that this is not what the plain HTTP server itself does, then enforcing a "307 internal redirect" to just HTTPS is not admissible. (As far as I can tell, this requirement is not explicitly stated on hstspreload.org, but can only be found out by actually trying to set up the HSTS preload.)

对于您的问题,我没有完整的答案,但是我可以提供您提出的几点更多信息:

I have no full answer to your question, but I can provide a bit more information on a few points you raise:

如果要提供重定向,则该重定向必须具有HSTS标头,而不是重定向到的页面.

If you are serving a redirect, that redirect must have the HSTS header, not the page it redirects to.

请注意 hstspreload.org 的确切(当前)报价:

Please note the exact (current) quote from hstspreload.org:

如果您要从 HTTPS站点提供其他重定向,则该重定向必须仍然具有HSTS标头(而不是其重定向到的页面).

If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (rather than the page it redirects to).

这与以下几点有关:

据我所知,在进行重定向时无法将诸如HSTS标头之类的内容提供服务...

As far as I know there is no way to serve such thing as a HSTS header when doing a redirect ...

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

It is completely possible that a HTTP redirect response also has an HSTS header. This only means that the HTTP redirect response also contains a Strict-Transport-Security header field with suitable parameters. For example, using SWI-Prolog as HTTP server, you can emit such responses like this:


?- 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 时,才允许使用此标头字段(否则,攻击者可能会通过未经身份验证的连接将流量强制发送到其他端口!).实际上,标头绝不能出现在HTTP→ HTTPS重定向中,因为它使用了未经身份验证的连接,如果(错误地) 发生在纯HTTP上,客户必须忽略它.

Note that this header field is only admissible when TLS is already being used (otherwise, an attacker could force traffic to a different port via a connection that is not authenticated!). In fact, the header must not occur in the HTTP→HTTPS redirect, because it uses an unauthenticated connection, and if it (incorrectly) does occur over plain HTTP, the client must ignore it.

现在是您问题的实际要点:

Now to the actual main point of your question:

这带来了巨大的重定向稀释 SEO问题(更不用说链式重定向并不理想的事实了.)

This poses a huge redirect dilution SEO problem (not to mention the fact that chained redirects are not ideal).

我完全同意,链接重定向远非理想之选,对于像我们这样的(常见!)设置,似乎目前还没有办法解决.

I completely agree that the chained redirects are far from ideal, and there seems to be no way around this with such (common!) setups as ours, at least not currently.

但是,我个人希望附加重定向的影响不会对您网站的排名产生太大影响:从理论上讲,一旦搜索引擎发现您的网站位于HSTS预加载列表中,它应该关心的就是HTTPS版本(因为这也是支持HSTS预加载的浏览器会执行的操作!).因此,最终只能得到一个重定向,即https://DOMAINhttps://www.DOMAIN重定向,应该与您当前的情况相当.至少那是我有些天真的希望.在此重定向中,请确保包含HSTS标头,因为这是进入预加载列表的要求.当然,确切的配置详细信息取决于您的具体Web服务器.

However, my personal hope is that the impact of the additional redirect will not impact your site's rank a lot: Theoretically, once a search engine sees that your site is in the HSTS preload list, all it should care for is the HTTPS version of it (because that's also what browers that support HSTS preload will do!). Therefore, you end up with only a single redirect, namely the https://DOMAINhttps://www.DOMAIN one, which should be rather comparable to your current situation. At least that's my somewhat naive hope. In this redirect, make sure that the HSTS header is included, since this is a requirement to get into the preload list. Of course the exact configuration details depend on your concrete web server.

此外,请注意,即使在 进入HSTS预加载列表之后,也无法恢复原始重定向链.这是因为持续要求部分指出:

Also, note that you cannot reinstate the original redirect chain even after you have made it into the HSTS preload list. This is because the Continued requirements section states:

您必须确保您的网站始终满足提交要求.

这篇关于HSTS预加载列表-www站点可能存在SEO问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆