Ответ 1
Поставьте ниже условия ввода:
<add input="{HTTPS}" pattern="on" />
Вместо:
<add input="{HTTPS}" pattern="off" />
У меня есть приложение, которое я разместил в IIS 7.0. Где я должен убедиться, что он работает только по HTTPS, а не по HTTP, поэтому я включил приведенное ниже правило в мою корневую конфигурацию.
<rewrite>
<rules>
<rule name="HTTP to HTTPS redirect" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="off" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Found" />
</rule>
</rules>
</rewrite>
После добавления этого правила, когда я пытался получить доступ к своему приложению, я получаю сообщение об ошибке ниже:
Страница вызвала слишком много перенаправлений. Очистка файлов cookie для этого сайта или разрешение сторонних файлов cookie может решить проблему. Если нет, возможно, это проблема конфигурации сервера, а не проблема с вашим компьютером. Вот несколько советов: Перезагрузите эту страницу позже. Узнайте больше об этой проблеме.
Поставьте ниже условия ввода:
<add input="{HTTPS}" pattern="on" />
Вместо:
<add input="{HTTPS}" pattern="off" />
У нас есть приложение ASP.NET, размещенное на AWS с балансировкой эластичной нагрузки, и правило в вопросе с принятым ответом не сработало для нас и продолжало вызывать бесконечные перенаправления.
Это правило, которое окончательно сработало для нас:
<rewrite>
<rules>
<rule name="HTTPS Rule behind AWS Elastic Load Balancer Rule" stopProcessing="true">
<match url="^(.*)$" ignoreCase="false" />
<conditions>
<add input="{HTTP_X_FORWARDED_PROTO}" pattern="^http$" ignoreCase="false" />
</conditions>
<action type="Redirect" url="https://{SERVER_NAME}{URL}" redirectType="Found" />
</rule>
</rules>
</rewrite>
Мой случай мне нужно поставить так:
<rewrite>
<rules>
<rule name="HTTP to HTTPS redirect" stopProcessing="true">
<match url="(.*)" ignoreCase="false" />
<conditions logicalGrouping="MatchAny">
<add input="{HTTP_X_FORWARDED_PROTO}" pattern="^http$" />
<add input="{HTTPS}" pattern="on" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Found" />
</rule>
</rules>
Для IIS 10 (Windows Server 2016) Я следовал инструкциям из здесь, которые генерируют несколько иной конфигурации XML для перезаписи:
<rewrite>
<rules>
<rule name="HTTP 2 HTTPS" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<conditions logicalGrouping="MatchAny">
<add input="{HTTPS}" pattern="off" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Found" />
</rule>
</rules>
</rewrite>
Шаблон off
и совпадение только *
.
Также, как упомянул SNag, у нас был сайт, который сидит за ELB на Amazon. Попытка применить правило перезаписи без следующего входного заголовка приводила к бесконечным перенаправлениям. Похоже, это связано с необходимостью ввода типа HTTP_X_FORWARDED_PROTO, как показано ниже: <add input="{HTTP_X_FORWARDED_PROTO}" pattern="^http$" ignoreCase="false"/>
.
Из документации AWS "Ваше приложение или веб-сайт могут использовать протокол, сохраненный в заголовке запроса X-Forwarded-Proto, для отправки ответа, перенаправляющего на соответствующий URL". Мы используем ELB с DNS-записями для пересылки на сервер с сайтом на нем.
Я использую Liquid Web Cloud Sites и столкнулся с точно такой же проблемой.
Я попробовал решение здесь, но оно не сработало для того, что мне было нужно из-за этого условия:
<add input="{HTTPS}" pattern="off" />
Как это имеет OP, это означает, что "сопоставьте и внедрите это правило, когда HTTPS выключен". И принятое решение для этого вопроса просто инвертирует это и соответствует правилу, когда HTTPS включен. Это решило проблему с бесконечным циклом, но только потому, что мое правило было некорректно сопоставлено - я на самом деле хочу изменить запрос на HTTPS только когда HTTPS выключен. Таким образом, ни один из моих HTTP-запросов не пересылался.
Интересно, что ни один из моих HTTPS-запросов также не переадресовывался, и из этого (и нескольких других тестов, которые я сделал) я определил, что, хотя браузер показывает HTTPS, сервер обрабатывает его как HTTP-запрос. Таким образом, сервер всегда полагает, что он получает HTTP-запрос, и всегда игнорировал правило (которое теперь определяет только те запросы на совпадение, для которых включен HTTPS, т.е. никогда).
Через несколько часов исследований и тестов я пришел к выводу, что проблема, аналогичная описанной здесь, кратко изложена здесь:
Для снижения затрат [многие хостинг-провайдеры устанавливают] сертификат SSL на шлюзе TMG, и этот шлюз просто переписывает запрос в стандартный HTTP при передаче его на реальный веб-сервер. Таким образом, к моменту, когда запрос попадает в IIS и ваше веб-приложение, это стандартный запрос HTTP.
,
В конце концов я поговорил с командой из Liquid Web, которая указала мне направление на помощь, спрятанную на их собственном сайте, которая решила эту проблему. Они предложили мне использовать следующее правило переписывания, которое исправило это:
<system.webServer>
<rewrite>
<rules>
<rule name="Redirect to HTTPS" stopProcessing="true">
<match url=".*"/>
<conditions>
<add input="{HTTP_CLUSTER_HTTPS}" pattern="^on$" negate="true"/>
<add input="{HTTP_CLUSTER_HTTPS}" pattern=".+" negate="true"/>
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{SCRIPT_NAME}" redirectType="SeeOther"/>
</rule>
</rules>
</rewrite>
</system.webServer>
Я надеюсь, что это может работать для других в аналогичной ситуации.