我有一个有趣的问题，就是 HTTPS 端口没有得到正确处理。这是一个相对较小的问题，我敢打赌它很容易解决，我只是没有想到它。
我们有一个使用 IIS 6 服务的网站，www.mylongdomainname.com。我们有一个通过 https://www.mylongdomainname.com 处理的安全门户.现在我们有几个我们通过电话使用的虚荣和营销 URL，如 www.shortname.com 等。我有两个网站设置，一个处理所有请求，标题为 www.mylongdomain.com，它实际上为网站提供服务。另一个接受任何流量并永久重定向到 www.mylongdomain.com。这样，如果我们再添加任何域，它们都将以一个结束，它还会将 mylongdomain.com 重定向到 www.mylongdomain.com。
这里一切正常。现在的问题是，当我用谷歌搜索“shortname.com”时，返回的第一个结果与我用谷歌搜索“mylongdomain”时的结果相同，但是，谷歌已经能够通过 https://shortname.com 抓取其他页面。并以这种方式索引它们。我们没有这些其他域的 SSL 证书，因此当您点击进入时，您会收到一个令人讨厌的不可信错误。
如果我们不通过电话使用这些 URL，这真的不是问题，而且你们都知道有多少人不知道 URL 栏和搜索框之间的区别。
有什么建议或提示吗？
最佳答案
我会设置一个重定向，以便 https://shortname.com发送至http://shortname.com使用 301(永久)重定向。这将立即结束令人讨厌的不受信任的错误。此外，这也会导致 Google 缓慢但肯定地更新其索引。
有多种方法可以做到这一点。如果您使用的是 IIS7，则可以使用 URL Rewrite Module并编写重定向规则来处理它。
或者，如果您不在 IIS7 上，则编写一些代码来完成此操作可能是完全可以接受的。我 wrote some ASP.NET我已经用了很多次来处理这个 HTTP/HTTPS 重定向。在您的特定情况下，您可以简单地使用我的代码并在 global.asax 的 Application_BeginRequest 函数中调用 SetSSL(False)。
关于IIS、重定向和 HTTPS，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2426858/