Комментарии 28
поэтому проверять лучше старым браузером.
простите что доколебался до мелочи не по сабжу, но проверять такие вещи лучше вообще не браузером, для этого есть более подходящие и предсказуемо работающие утилиты, например curl
Есть вероятность, что новое поколение админов не знает, что такое rewrite, и вполне логично спрашивает, в каком месте описания ingress controller эту фигню надо писать и нафига.
И они правы.
А можно по-подробнее, почему реверс-прокси nginx не должен светить в сеть?
Что делать в плане мониторинга? Так вы же расписали - фиксировать ситуацию "руки из ж..." с детализацией а) неверные перенаправления б) неверные SSL в) особые извращения (это про astrobl) и т.д.
Ну а если www и без www контентно одинаковые и технически всё ОК (SSL) - значит для человека всё хорошо.
некоторые пользователи старой школы, набирающие адрес сайта руками, непременно добавляют к нему «www.» (или за них это делает браузер) и впадают в ступор, когда в ответ видят «host not found».
Кстати, я попадался наоборот с сайтами местных госорганов. Набираешь без www, а А записи для домена нет. Но это было давно.
На сколько можно судить браузер хром может проанализировать SEO сайта и выдать рекомендации в плане правильности маршрутизации и переадресаций к каноническому виду URL.
И особого смысла перебирать варианты вручную уже нет.
Плюс есть еще множество онлайн инструментов проверки. (ssllabs.com, amplify.nginx.com, mxtoolbox.com и куча других по запросу) которые дадут вменяемые рекомендации по настройке не только базовых переадресаций но и множества других параметров, о которых можно было бы только догадываться.
Плюс и Google и Яндекс в поисковых панелях дают рекомендации.
Вообще, сама по себе проблема неканонических URL скорее всего связана с тем, что в самых популярных серверных приложениях (apache и nginx) настройка условной переадресации происходит несколько неожиданным образом.
Вместо привычной для любого программиста конструкции if(запрос содержит www или http://) {переходи по ссылке https://} нужно создавать отдельные конфигурации виртуальных серверов с www и с http и в них создавать перенаправление.
Однако, все это не сильно актуально, так как все настройки все более и более автоматизируются различными панелями управления и в скором времени исчерпают себя так же как ушли в прошлое кодировки страниц и прочие неудобства.
Да и кто в наше время набирает запросы вручную?
нужно создавать отдельные конфигурации виртуальных серверов с www и с http
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.
RewriteRule (.*) https://ifap.ru%{REQUEST_URI} [NE,R=301]Это для Apache, 3 строчки в .htaccess
Все верно, я скорее думал о nginx а сослался на оба сразу.
server {
listen 80;
server_name XXX www.XXX;
return 301 https://XXX$request_uri;
}
Но и с Апач тоже не все так просто. Обработка .htaccess будет не в первую очередь, а после обработки серверного блока и всевозможных <Directory ... > <Location >
Да и сам mod_rewrite очень не прост в настройке и эксплуатации, чего только стоят ключи в квадратных скобках.
Вы правы и по Nginx и по Apache существует масса примеров, документации на любом языке, генераторов конфига и даже исходные коды серверов доступны.
Будет работать и .htaccess, и даже index.php в котором можно проверять и перенаправлять запрос.
Я говорю только о том, что привычное для любого технаря ветвление процесса в конфигах работает не эффективно, порой неожиданно, а зачастую и вовсе не работает.
Даже самые простые действия с конфигами требуют изучения документации, практических экспериментов и непрерывного тестирования.
Естественно, ресурсы с низким бюджетом или сделанные давно и формально будут содержать ошибки и пренебрегут как тестированием, так и изучением мануалов.
Однако, с течением времени все это исправится благодаря тому, что технические вопросы настройки серверов будут изолированы от рядовых пользователей. Да и сейчас уже гораздо проще использовать хостинг, нежели изобретать велосипед и копаться в настройках.
Если вначале проверять на www, то обычно редирект идёт с http на http://www, и только второй уже с http на https. Поэтому первый и не нравится чекерам. Логично сразу делать http://site → https://www.site, тогда и проверка пройдет, и один редирект сэкономится.
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.
RewriteRule (.*) ifap.ru%{REQUEST_URI} [NE,R=301]
здесь проверка сделана одним правилом: если А и/или B, то редирект, но если поменять местами строки 1 и 2, чекеры через раз недовольны.
Скорее всего дело в том, что здесь используются "ленивые вычисления" - т.е. до если первое условие выполнено, то второе вычислять и не нужно (там ведь OR).
Об этом сказано в документации, но очень завуалированно:
It has to be kept in mind that conditions follow a short circuit logic in the case of the 'ornext|OR' flag so that certain conditions might not be evaluated at all.
Поэтому в данном случае от перемены мест результат меняется.
И еще один вопрос: в RewriteRule выше - как происходит upgrade до HTTPS? Там есть еще какая-то инструкция, что вместо http нужно отдать https, или это просто случайно пропущено, и должно быть так?
RewriteRule (.*) https://ifap.ru%{REQUEST_URI} [NE,R=301]
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.
RewriteRule (.*) https://ifap.ru%{REQUEST_URI} [NE,R=301]Т.е. это должно работать следующим образом:
— если http, то 301 на https без www
— если с www, то 301 на https без www
и так оно и работает, но если поменять условия местами, то, судя по реакции валидаторов, Apache сначала проверяет наличие www и переадресует на без www, а потом проверяет наличие https и выполняет второй редирект. Копать я не стал, просто поменял условия местами и все заработало как ожидается, но вот такой странный глюк словил.
Да, именно https:// в RewriteRule мне и не хватало :)
Что же касается первой части моего ответа. Скорее всего валидаторы проверяют не поведение сайта, а сам код конфигов? Тогда представьте, что в изначальной форме, где проверка на HTTPS идёт второй:
RewriteCond %{HTTP_HOST} ^www\. [OR]
RewriteCond %{HTTPS} !=on
Если сайт идёт с www, то сработает первое условие, и уже не важно, был ли сайт с HTTPS или без. Условие HTTP(s) можно не проверять, т.к. действие (RewriteRule) всё равно запускать. Именно это и называется ленивым вычислением.
Я бы сказал, что это ошибка проверяющих, а не конфига.
http://www -> fail
http://ifap -> pass
https://www -> pass
https://ifap -> pass
Ошибка проверки не должна появляться, если проверяется не текст конфига, а поведение сайта снаружи, т.к. в данном случае правило сработает, а почему - для валидатора не видно.
Разве эта "проблема" не решается одной CNAME записью в панели управления DNS?
CNAME www.site.com site.comНастраиваем перенаправление с www на основной домен и все счастливы.
поддомен – WWW – указывали на одно и то же обстоятельство
В конце 90х, когда появились сайты с пиратской музыкой/фильмами и т.д. которые занимали много места на HDD и все не влазили на один сервер, который мог быть обычный ПК, очень часто были домены WWW2., WWW3. которые шли на другой сервер. И частенько при добавлении новинок сразу делались "зеркала" на другие серваки.
На том единственном сайте, который меня угораздило "поддерживать", просто сделал прозрачный редирект со всевозможных вариантов на вариант с https и без www на уровне апача, без долгих раздумий и страданий
Даже и не думал, что на эту тему копья ломаются вообще
Проклятие поддомена WWW: чеклист молодого админа