У двух разных хостеров происходило следующее. При попытке использовать редиректы с несекьюрных материалов на секьюрные, контент не загружался, а сервер репортовал ERR_TOO_MANY_REDIRECTS (310). Проблема конкретно c zenon разрешилась.
Причем, в случае первого хостера, сайт нормально работал в течение полугода, переконфигурация, установка дополнительных модулей в CSM не делалась. Административный вход автоматически перенаправлялся через https. И в один прекрасный день - циклический редирект при попытке входа в админку. Более того, любая попытка редиректа http->htps на стороне сервера приводит к этому ахтунгу. Менеджеры саппорта хостера оказались стойкими партизанами, терморектальный криптоанализ не помог. Проблема, как говорится, "на вашем конце" :)
Но теперь-то мы знаем (а сколько часов личного времени было убито на осознание этого факта...), что, и у кого не в порядке с концом :) Закончим вступление на этой фаллической ноте.
И вот, на заваленных говонопорнухой просторах всемирной паутины нашлось следующее. В этом выгребном котловане IT приятно чувтсвовать себя не одиноким.
So the problem is that.
...Network Solutions® uses a proxy SSL this does not allow the use of server-side variables to detect HTTPS (secure). All server-side coding will always detect HTTP (non-secure), and for programs that attempt to redirect non-secure connections (http://) to a secure connection (https://) will result in an infinite loop and server error after 30 seconds.and this give this little code snippet
То есть, говоря по-русски, SSL у провайдера ходят через проксю, которая не передает переменные состояния на бэкэнд (в нашем случае - Апач). И сам апач не может определить через какой протокол реально пришел запрос - http или https, для него все по-прежнему - http. Посему - происходит вот что - к Апачу приходит запрос - покажи-ка мне URI админки. HTACCESS (ну, или плагин-редиректор) перезаписывает для этого URI протокол, делает перенаправление на https, а уже перезаписанный запрос опять приходит как http, и так до посинения Apache.
Далее предлагают обрабатывать содержимое документа на стороне клиента, вставляя в страницы следующий JavaScript:
<script language="javascript">
if (document.location.protocol != "https:")
{
document.location.href = "https://subdomain.yourdomain.com" + document.location.pathname;
};
</script>
После чего почти что все, конечно, начинает работать, хоть и через соответствующее отверстие. Однако, как и следовало ожидать - то, до чего клиентский скрипт добраться не может - остается прилинкованным по http.
This works fine except for all the connects to like ssl style sheets and js files are still referenced over http not https is there any javascript that will change all references to use ssl or any other Solutions?
Итого - пока хостер не разберется с улучшениями и оптимизациями, которые он неявно проделал со своим концом, со стороны бедного клиента будет вытекать нечто непотребное. Вывод пока никакой - ручками набираем протокол, если надо идти в админку :(
А вот что выяснилось при общении с хостером, у которого в техсаппорте есть нормальные люди (zenon.ru) и да, можете считать это рекламой, мне "по барабану".
В связи со сложным механизмом реализации SSL соединений внутри наших серверов, распознавание ssl / не ssl возможно только по флагу HTTP:X-SSL-Connect
Чтобы перенаправлять все http-запросы на https (после подключения услуги SSL), нужно прописать в корневой папке .htaccess строки:
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP:X-SSL-Connect} !(^yes)
RewriteRule (.*) https://www.site.ru/$1И это, черт побери, работает!
Путем долгого хруста мозгом проблема разрешилась. Вводные:
- Надо, чтобы джумла и ее плагины могли делать редиректы в/из SSL
- Не надо, чтобы для этого приходилось плясать с бубном вокруг .htaccess
- Серверная конфигурация zenon использует ngnix для обработки SSL запросов, с апачем общается по локальному http, серверные переменные апача, в т.ч. HTTPS, не устанавливаются.
- Джумловые редиректы входят в бесконечный луп, и вуаля, ошибка 310
Что сделал. Раз надо, чтобы для секьюрных коннекций у апача выставлялась переменная HTTPS, так и сделаем же это. Например, через .htaccess, с помощью модуля апача mod_setenvif. Пишем где-то вначале .htaccess
SetEnvIfNoCase X-SSL-Connect (^yes) HTTPS=on
Эта форма директивы SetEnv проверяет кастомное поле "X-SSL-Connect" HTTP хидера, которое выставляется ngnix, и если оно установлено в "yes", независимо от регистра, взводит переменную окружения сервера апач: HTTPS=on.
После этого плагины редиректа джумлы перестают сходить с ума, и все начинает работать как надо, без ошибок 310. По крайней мере, пока работает. Буду тестировать дальше, поглядим, насколько жизнеспособно это решение.