Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
поэтому проверять лучше старым браузером.
простите что доколебался до мелочи не по сабжу, но проверять такие вещи лучше вообще не браузером, для этого есть более подходящие и предсказуемо работающие утилиты, например curl
Вы правы, но не хочется сразу пугать админов, которые не умеют в rewite, заклинаниями высшего порядка, типа curl ;)
Есть вероятность, что новое поколение админов не знает, что такое rewrite, и вполне логично спрашивает, в каком месте описания ingress controller эту фигню надо писать и нафига.
И они правы.
Не наговаривайте на госадминов, IG я видел у них раз или два, обычно Nginx или Apache своей голой жопой мордой в Интернет светит, нередко любезно сообщая свою версию, что снимает вопросы, откуда у них на серверах берутся всякие интересные CVE-2016-* и более ранние ;) Так что про RewriteEngine и т.п. должны хотя бы слышать, а дальше — Гугл в помощь, было бы желание.
А можно по-подробнее, почему реверс-прокси nginx не должен светить в сеть?
Я имел в виду, что исследуемые нами веб-сервера, как правило, не «прикрыты» ничем, тем более не используют балансеры. Впрочем, и нету надо — не те задачи, не те нагрузки. А когда их прикрывают, очумелые ручки дают себя знать с новой силой (ключевое слово: Ingress).
Что делать в плане мониторинга? Так вы же расписали - фиксировать ситуацию "руки из ж..." с детализацией а) неверные перенаправления б) неверные 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 просто не помню, но тоже не бином Ньютона. С Апачем просто, мануалы как настроить переадресацию в широком ассортименте, в т.ч. на русском. Нюансы скорее возникают, в каком порядке задавать условия: сперва проверка наличия www. в адресе или схемы? И вот тут начинается нечто странное: хотя инструкция единая, если первой в ней поставить проверку на наличие www., различные чекеры не видят принудительной переадресации на https, хотя она выполняется. Почему — для меня загадка, но стоит изменить порядок проверки и чекеры довольны.
Вы правы и по Nginx и по Apache существует масса примеров, документации на любом языке, генераторов конфига и даже исходные коды серверов доступны.
Будет работать и .htaccess, и даже index.php в котором можно проверять и перенаправлять запрос.
Я говорю только о том, что привычное для любого технаря ветвление процесса в конфигах работает не эффективно, порой неожиданно, а зачастую и вовсе не работает.
Даже самые простые действия с конфигами требуют изучения документации, практических экспериментов и непрерывного тестирования.
Естественно, ресурсы с низким бюджетом или сделанные давно и формально будут содержать ошибки и пренебрегут как тестированием, так и изучением мануалов.
Однако, с течением времени все это исправится благодаря тому, что технические вопросы настройки серверов будут изолированы от рядовых пользователей. Да и сейчас уже гораздо проще использовать хостинг, нежели изобретать велосипед и копаться в настройках.
Если вначале проверять на www, то обычно редирект идёт с http на http://www, и только второй уже с http на https. Поэтому первый и не нравится чекерам. Логично сразу делать http://site → https://www.site, тогда и проверка пройдет, и один редирект сэкономится.
Смотрите:
здесь проверка сделана одним правилом: если А и/или B, то редирект, но если поменять местами строки 1 и 2, чекеры через раз недовольны.
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]
Да, там OR, но достаточно соответствия любому из условий или обоим сразу, чтобы произошел редирект на https. Возможно Вас смутило то, что при цитировании была утеряна часть кода, которая в оригинале выглядела так:
Т.е. это должно работать следующим образом:
— если http, то 301 на https без www
— если с www, то 301 на https без www
и так оно и работает, но если поменять условия местами, то, судя по реакции валидаторов, Apache сначала проверяет наличие www и переадресует на без www, а потом проверяет наличие https и выполняет второй редирект. Копать я не стал, просто поменял условия местами и все заработало как ожидается, но вот такой странный глюк словил.
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: чеклист молодого админа