Request.Url.Scheme дает http вместо https на загруженном балансе сайте

Я тестирую новый загружаемый баланс, и https настроен на уровне балансировки нагрузки, а не на уровне сайта. Кроме того, этот сайт будет всегда https, поэтому мне не нужны удаленные атрибуты https и т.д. URL-адрес отображает https, но он недоступен в моем коде. По этой причине у меня есть несколько проблем.

Request.Url.Scheme всегда http:

public static string GetProtocol()
        {
            var protocol = "http";
            if (HttpContext.Current != null && HttpContext.Current.Request != null)
            {
                protocol = HttpContext.Current.Request.Url.Scheme;
            }
            return protocol;
        }

То же самое с этим базовым url, протокол http

public static string GetBaseUrl()
        {
            var baseUrl = String.Empty;

            if (HttpContext.Current == null || HttpContext.Current.Request == null || String.IsNullOrWhiteSpace(HttpRuntime.AppDomainAppPath)) return baseUrl;

            var request = HttpContext.Current.Request;
            var appUrl = HttpRuntime.AppDomainAppVirtualPath;

            baseUrl = string.Format("{0}://{1}{2}", request.Url.Scheme, request.Url.Authority, appUrl);

            if (!string.IsNullOrWhiteSpace(baseUrl) && !baseUrl.EndsWith("/"))
                baseUrl = String.Format("{0}/", baseUrl);

            return baseUrl;
        }

Теперь самой большой проблемой является ссылка на js файлы и шрифты google, упомянутые в таблицах стилей. Я использую//здесь без http или https, но они рассматриваются как http и я вижу смешанное содержимое, заблокированное в FireBug.

Как я могу решить эту проблему?

Ответы

Ответ 1

Как вы сказали, завершение HTTPS выполняется на уровне балансировки нагрузки ( "https настроен на уровне балансировки нагрузки" ), что означает, что исходная схема может не попасть на сайт в зависимости от конфигурации балансировки нагрузки.

Похоже, в вашем случае LB настроен постоянно разговаривать с сайтом по HTTP. Поэтому ваш сайт никогда не увидит исходную схему на HttpContext.Request.RawUrl (или аналогичные свойства).

Исправлено: обычно, когда LB, прокси или CDN настроены таким образом, есть дополнительные заголовки, которые указывают исходную схему и, возможно, другие параметры входящего запроса, такие как полный URL-адрес, IP-адрес клиента, который не будет непосредственно виден сайту за таким прокси-устройством.

Ответ 2

Я знаю, что это старый вопрос, но, столкнувшись с той же проблемой, я обнаружил, что если я посмотрю на UrlReferrer свойство объекта HttpRequest, значения будут отражать то, что было на самом деле в адресной строке браузера клиента.

Так, например, с UrlReferrer я получил:

Request.UrlReferrer.Scheme == "https"
Request.UrlReferrer.Port == 443

Но для этого же запроса с помощью свойства Url я получил следующее:

Request.UrlReferrer.Scheme == "http"
Request.UrlReferrer.Port == 80