Как использовать [ИЛИ] или заменить в файле .htaccess?

Резюме В [OR] flag не работает последовательно на разных серверах. Подробности и вопрос ниже.

У меня есть веб-сайт, размещенный на Godaddy, и я написал этот код для .htaccess файл для перенаправления пользователей на https версия моего сайта. Отлично работает.

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off [OR]
    RewriteCond %{HTTP_HOST} !^www\. [NC]   
    RewriteRule ^(.*)$ https://www\.firstsite\.com%{REQUEST_URI} [R=301,L]
</IfModule>

Я использовал то же самое .htaccess файл для другого сайта, размещенного в Network Solutions, и это привело к сбою сайта. Это вызвало эту ошибку.

Эта страница не работает
www.secondsite.com слишком много раз перенаправлял вас.
ERR_TOO_MANY_REDIRECTS

Я удалил [OR] флаг для сайта сетевых решений и сайта, загруженного без ошибки. Это обновленный код.

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{HTTPS} off
    RewriteCond %{HTTP_HOST} !^www\. [NC]
    RewriteRule ^(.*)$ https://www\.secondsite\.com%{REQUEST_URI} [R=301,L]
</IfModule>

К сожалению, без [OR] он не перенаправляет на основе первого условия, RewriteCond %{HTTPS} off. Однако он по-прежнему перенаправляет на основе второго условия RewriteCond %{HTTP_HOST} !^www\. [NC]

Я не знаю, как это исправить. мне нужно [OR] но я не могу его использовать. Есть ли способ использовать [OR] иначе или есть альтернатива подобным ситуациям? Спасибо!

.htaccess

В [OR] flag не работает последовательно на разных серверах.

Это (почти) невозможно. В OR flag - это фундаментальная конструкция / оператор в mod_rewrite. Если эта конструкция не работает должным образом, значит, у вас серьезная проблема с вашим сервером, требующая переустановки или поиска нового хоста. Такой сценарий невероятен.

Однако гораздо более вероятно, что один из операндов в выражении OR'd не соответствует вашим ожиданиям. т.е. В этом случае одна из переменных сервера HTTPS или HTTP_HOST не настроен так, как вы ожидали. И из двух, более вероятно, что HTTPS переменная сервера не устанавливается (или не устанавливается, как вы ожидаете) - как я уже упоминал в своем комментарии. Это вполне «нормально» и зависит от конфигурации вашего сервера и от того, как управляется сертификат SSL. например. Если вашим сертификатом SSL управляет внешний прокси (например, CloudFlare), то HTTPS переменная сервера, вероятно, не установлена. Казалось бы, это согласуется с теми результатами, которые вы видите.

Отладка

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

NB: во время тестирования предпочтительно использовать временные (302) перенаправления, которые не кешируются браузером. 301 (постоянное) перенаправление жестко кэшируется браузером, поэтому вы должны убедиться, что кеш отключен, что делает тестирование проблематичным. Перед продолжением убедитесь, что кеш очищен.

Попробуйте (временно) изменить это на перенаправление HTTP на HTTPS (только), т.е. удалите канонизацию www. У вас все еще есть цикл перенаправления? Например:
```
RewriteCond %{HTTPS} off
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R,L]
```
(В стороне: Нет необходимости избегать точек на RewriteRule замена - это обычная строка, а не регулярное выражение.)
Если вышеуказанное вызывает цикл перенаправления, проверьте, какая переменная сервера HTTPS содержит. т.е. Удалите указанное выше перенаправление HTTP на HTTPS и добавьте вместо него следующее:
```
RewriteRule ^foo$ /?HTTPS=%{HTTPS} [R,L]
```
И получить доступ к URL https://example.com/foo прямо. Вы должны быть перенаправлены на https://example.com/?HTTPS=<value>. Что <value>? (The <value> может быть пустым.)
Проверьте заголовки HTTP-запросов на своем применение видит. Если вы используете PHP, проверьте $_SERVER и $_ENV суперглобальные массивы и специально проверять индексы HTTPS, SERVER_PORT, SCRIPT_URI и HTTP_X_FORWARDED_PROTO (что соответствует X-Forwarded-Proto заголовок - если установлен вообще). Однако могут быть и другие, специфичные для вашего сервера. Например, некоторые хосты устанавливают переменная окружения называется HTTPS (в отличие от одноименной серверной переменной). Добавьте к своему вопросу то, что вы нашли.

Если вы видите X-Forwarded-Proto заголовок запроса, то вы находитесь за интерфейсным прокси, например этот вопрос на StackOverflow.

Смотрите также этот вопрос о профессиональных веб-мастерах для аналогичного «обсуждения» и возможного решения.

ОБНОВИТЬ: ... сайт, размещенный на Сетевые решения...

Я только что немного покопался в "Сетевых решениях" (NS), и кажется, что это не может быть возможно!? Я нахожу это совершенно ошеломляющим, если это правда, однако я думаю, что это все равно должно зависеть от того, как и какой тип сертификата SSL установлен?

(По-прежнему проверяйте заголовки HTTP-запросов и переменные сервера / скрипта, как указано выше.)

Однако Документ поддержки сетевых решений о перенаправлениях SSL состояния:

Network Solutions® использует прокси SSL, что не позволяет использовать серверные переменные для обнаружения HTTPS (безопасный). Все кодирование на стороне сервера всегда будет обнаруживать HTTP (небезопасный), а для программ, которые пытаются перенаправить незащищенные соединения (http://) к защищенному соединению (https://) приведет к бесконечному циклу и ошибке сервера через 30 секунд.

Вы можете использовать клиентскую программу (например, javascript), чтобы определить, безопасна ли она, и перенаправить ее, если это не так. Вы можете использовать приведенный ниже код для создания перенаправления. Просто измените код так, чтобы он перенаправлял на правильный безопасный домен, и добавьте его в HTML любых конфиденциальных страниц, которые могут у вас быть.
<script language="javascript">
if (document.location.protocol != "https:")
{
document.location.href = "https://subdomain.yourdomain.com" + 
document.location.pathname;
};
</script>

«Прокси-SSL» должен идентифицировать себя или, по крайней мере, определять состояние HTTPS в «проксируемом» запросе к серверу приложений. Однако это означает, что это не так.

См. Также следующий связанный вопрос о StackOverflow. Однако представленные там «другие» решения не кажутся жизнеспособными ИМО. В конечном итоге может показаться, что это ссылка на приведенный выше документ поддержки (и решение JavaScript) от NS.
https://stackoverflow.com/questions/4686668/https-redirect-for-network-solutions