серверный пул https в лазурном шлюзе и цикл перенаправления htaccess

У меня есть правило перезаписи htaccess:

RewriteCond %{HTTP_HOST}: ^(?:www\.)?samplesite\.net
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

на двух лазурных виртуальных машинах под управлением IIS. У меня есть шлюз приложений, который находится впереди, у которого есть внутренний пул Https с серверами сертификатов двух лазурных виртуальных машин.

У меня есть многосайтовый прослушиватель https на шлюзе, который прослушивает трафик https на шлюз с определенным URI www.samplesite.net. Есть прикрепленное правило, которое использует пул backendHttps.

На виртуальных машинах размещено несколько сайтов, и я хочу перенаправить HTTP на HTTPS только для этого сайта. У меня есть закрытый ключ для www.samplesite.net на шлюзе Azure для слушателя.

Если я укажу прямо на любую виртуальную машину, я успешно перенаправлюсь на HTTPS. Если я укажу на шлюз, я получаю слишком много ошибок перенаправления.

Если я не переписываю на сервере, я могу без проблем перейти на HTTPS или HTTP через шлюз.

Почему я получаю это перенаправление, если у меня есть сквозное шифрование?

Изменить: в отношении использования правил шлюза для перенаправления трафика:

Правила обрабатываются в том порядке, в котором они перечислены, и трафик направляется с использованием первого совпадающего правила независимо от специфичности. Например, если у вас есть правило, использующее базовый прослушиватель, и правило, использующее многосайтовый прослушиватель, оба на одном и том же порте, правило с многосайтовым прослушивателем должно быть указано перед правилом с основным прослушивателем, чтобы для многосайтового прослушивателя - правило сайта должно функционировать должным образом.

Edit2: Если кому-то интересно, я должен был сделать это:

RewriteCond %{HTTP_HOST}: ^(?:www\.)?samplesite\.net
RewriteCond %{HTTP_X_FORWARDED_PROTO} ^http$
RewriteRule ^(.*)$ https://www.samplesite.net%{REQUEST_URI} [L,R=302]

azure azure-application-gateway .htaccess
person MByrne    schedule 28.05.2018    source источник
comment
В качестве альтернативы правилу htaccess вы можете настроить правило, прикрепленное к прослушивателю http, для перенаправления на прослушиватель https. Таким образом, перенаправление обрабатывается на шлюзе приложения, а не на vm.   -  person Jason P    schedule 29.05.2018
comment
Чтобы помочь вам лучше, не могли бы вы поделиться кодом ошибки или сообщением.   -  person Zahid Faroq    schedule 29.05.2018
comment
@ Джейсон П, прости. Я также должен был упомянуть, что пробовал перенаправить на портале. Правило перенаправления не сработало. Я читал, что они выполняются в соответствии с порядком на портале. К сожалению, уже действуют более общие правила, которые мне пришлось бы удалить. Удаление других правил и слушателей нарушит работу других уже существующих сайтов. По крайней мере, пока я не смогу добавить их снова. Кроме того, каждый раз, когда я хочу, чтобы другой конкретный сайт перенаправлялся на Https, мне приходилось удалять общие правила и повторно добавлять их после правил для нескольких доменов.   -  person MByrne    schedule 29.05.2018

Ответы (1)


arrow_upward
0
arrow_downward

Мне нужно было проверить заголовок, пересылаемый со шлюза

> RewriteCond %{HTTP_HOST}: ^(?:www\.)?samplesite\.net 
> RewriteCond %{HTTP_X_FORWARDED_PROTO} ^http$ 
> RewriteRule ^(.*)$ https://www.samplesite.net%{REQUEST_URI} [L,R=302]

https://www.helicontech.com/isapi_rewrite/doc/examples.htm https://stackoverflow.com/a/41512717/7889282

https://sitecoreblog.marklowe.ch/2017/01/using-ip-geolocation-and-ssl-on-azure/

person MByrne    schedule 29.05.2018