检查Url是否以“http”或“https”开头，非安全Url是否可能以“https”开头？

我将我的网站发布到一个IIS服务器，我无法控制，并且我想从代码隐藏中了解，如果它的URL以“http”或“https”开头。检查Url是否以“http”或“https”开头，非安全Url是否可能以“https”开头？

首先，我想对我的地方这两种解决方案，都返回正确的值（“HTTP”）：

this.Request.Url.Scheme 

Request.IsSecureConnection

可以肯定的，我也装一个安全的SSL连接到自己的电脑的IIS ，并发布了相同的代码。这两个代码也都抓取了正确的值（https）。

但是，当我将其发布到使用“https”的我公司的IIS服务器时，它将返回为“http”。

这里会有什么问题？我注意到我尝试的URL可能不会被认为是一个安全的层，即使它以“https”开头（当我从谷歌浏览器调用页面时，它不会变成绿色并显示为安全），所以也许它不是一个安全层，它只是常规页面只能以“https”而不是http开头。这种情况可能吗？

来源

2016-01-06 Hakan Erdogan

一种可能性可能是您的Web应用程序前有代理或负载平衡器。它可能会在到达您的网站之前“卸载”SSL。

另外，正如您所指出的，只需在浏览器中指定https并不能保证您的SSL证书正常工作和正确配置。尝试使用https://www.ssllabs.com/ssltest/之类的工具来帮助识别问题。

来源

2016-01-06 12:18:10 cbp

谢谢。是的，我正在考虑某种代理屏障是可能的。我当然知道用“https”请求替换所有的“http”请求。但是，从您建议的工具测试中传递的网页。这意味着我实际上是一个安全的网站，但这些代码块无论如何都会返回“http”。据我所知，你基本上说：“有些东西在IIS上负责将请求中的”http“转换为”https“，但是你的代码无法理解，并且就像是http一样。”那是对的吗？你有关于如何证明/避免这个问题的想法吗？ –

想象一下，数据通过如下链传输：用户 - > Internet - >负载平衡器 - >服务器 - >应用程序。在这种情况下，通常只能通过SSL从用户传输到负载均衡器，但在负载均衡器和应用程序之间不需要麻烦。如果我们想象链中的代理，则可以拥有相同的场景。这可能会让您的应用程序更难以检查原始方案。然而，通常原始方案将被放置在诸如X-Forwarded-Proto的标题中。这是一个很大的话题，但Google关于X-Forwarded-Proto和SSL卸载。 – cbp

会做。感谢细节。 –

检查Url是否以“http”或“https”开头，非安全Url是否可能以“https”开头？

回答

相关问题