Извлечение URI запроса с прокси между

Question

Я занимаюсь разработкой веб-приложения, которое должно отправлять пользователям электронные письма с указанием просматривать определенные страницы, являющиеся частью исходного приложения.Мой текущий код для генерации ссылки якоря выглядит следующим образом:

String.Format("{0}{1}{2}{3}/{4}",
    Request.Url.Scheme, Uri.SchemeDelimiter, Request.Url.Host, 
    Request.ApplicationPath, path);

Цель состояла в том, чтобы он работал и ссылался на правильный сайт, независимо от того, запускал ли я сайт на сервере разработки, тестсервер или производственный сервер.Тем не менее, есть несколько недостатков, которые мне нужны, чтобы обойти помощь.

1. Request.Url.Scheme не будет работать во всех случаях для нас.Наш производственный сервер требует соединения https.Прокси перехватывает соединение https, расшифровывает запрос и перенаправляет его на наш веб-сервер.Таким образом, Request.Url.Scheme всегда будет показывать http
2. Request.Url.Host возвращает имя локального сервера нашего производственного сервера;Я думаю, что это также связано с проблемой прокси.
3. Прочитал другой пост, который предлагает использовать Request.Headers["host"].Не уверен, что это может быть связано с той же проблемой.

Кто-нибудь с немного большим знанием HTTP / HTTPS, перенаправления и обработки ASP.Net этой опасной кодекса (или может указать мне вправильное направление)?

Обычно, если пользователь получает электронное письмо от сервера dev.example.com, используя http, Uri в письме должно быть http://dev.example.com/page.aspx.Если пользователь использует рабочий сервер secure.example.com по протоколу https (который обрабатывается веб-прокси), ссылка должна быть https://secure.example.com/page.asx.

Answer 1

По моему опыту, связанному с внедрением системы единого входа, наш прокси-сервер не передавал никакой информации об исходном запросе.Мы не нашли способ обойти проблему https, которая была неудачной.

Я не на 100%, но я думаю, что пакет маршрутизации запросов приложений может позволить переписать возвращенные URL-адреса внутри html для работы вне прокси-сервера.Например, если вы вернете его как http://server.com/page.aspx, он может переписать его как https://server.com/page.aspx. Кроме того, вы можете указать правила, которые обновят http-соединение до https на прокси-сервере, который я считаю.Таким образом, у вас будет первоначальный http-запрос, который переходит на https.

Также вы, вероятно, хотите, чтобы ваш dev-сервер работал как можно ближе к вашему prod-серверу для этих самых проблем.