Почему ваш вебсайт canonical name должен быть 'www' (или 'app' или что-то еще)
URL-адрес сайта, начинающийся с 'www' , предотвращает отправку данных о посетителях (cookies) в непреднамеренные пункты назначения.
Я знаю, есть много статей на эту тему. Но я подумал, что было бы полезно написать об этом пост, потому что я не знал всех подробностей.
Я предполагаю, что доступ к вашему сайту можно получить из интернета, используя URL 'without-www' и URL 'with-www'. Эта статья не о выборе URL веб-сайта в маркетинговых целях. Даже если вы используете URL 'with-www' для своего веб-сайта, вы все равно можете сообщить URL 'without-www' своей аудитории.
Вместо этого эта статья посвящена техническим последствиям использования 'www' prefix или вообще никакого prefix .
Определения
Доменное имя Доменное имя - это уникальное имя, которое идентифицирует такую организацию, как веб-сайт в Интернете. Доменное имя всегда состоит из двух или более частей, разделенных точками.
Веб-адрес илиURL веб-адрес или URL-адрес - это местоположение организации в Интернете. Это может быть файл, веб-страница, веб-сайт.
Вершина домена Вершина домена - это корень домена. Например, example.org - это вершина домена. А www.example.org, mail.example.org называются поддоменами example.org. Вершиной домена также называется базовый, голый или голый домен.
Каноническое имя A canonical name, также называемое записью CNAME , представляет собой запись DNS, определяющую имя хоста компьютера или сервера. Она используется для добавления prefix , как 'www' в корневой домен.
Система доменных имен (DNS) Система доменных имен, или DNS, является децентрализованной системой для компьютеров, подключенных к Интернету. Ее часто называют телефонной книгой Интернета. Ее важнейшей функцией является преобразование URL в IP-адрес. Это делается серверами имен.
Серверы имен Серверы имен являются частью системы доменных имен (DNS). Если кто-то изменяет DNS-записи на сервере имен, то эти изменения распространяются на все серверы имен, являющиеся частью DNS. Они выполняют реальный перевод с URL на IP-адрес.
Что происходит, когда вы вводите URL-адрес в вашем браузере.
Прежде чем углубиться в детали, давайте подведем итог тому, как веб-страница отображается на вашем экране. URL, который вы вводите в браузере, отправляется на сервер имен. Сервер имен преобразует его в IP-адрес и возвращает его вашему браузеру. Ваш браузер подключается к этому IP-адресу и получает ресурс, часто веб-страницу.
Данные, которые отображаются в браузере, обычно выбираются тремя или четырьмя системами:
- Система доменных имен (DNS).
- (необязательно) Сервер proxy
- Веб-сервер, например Nginx, Apache
- Веб-приложение
Трансляция URL-адреса в IP-адрес осуществляется одной или несколькими DNS-записями.
Дополнительный сервер proxy является промежуточным сервером, который отделяет веб-сайт(ы) от интернета. Для простоты предположим, что в нашем соединении нет сервера proxy .
Веб-сервер может быть сконфигурирован несколькими способами. Он может перенаправить или переписать URL 'without-www' на URL 'with-www', или наоборот. Он также может перенаправить или переписать HTTP на HTTPS.
Веб-приложение получает URL от веб-сервера, обрабатывает его и возвращает веб-серверу данные запрашиваемого ресурса, файла или веб-страницы. Наконец, веб-сервер возвращает эти данные браузеру.
Переадресация: в 'without-www', в 'with-www' или без переадресации.
Конечно, ваш сайт должен быть доступен по URL, и большинство сайтов поддерживают URL 'without-www' и URL 'with-www'. Но как насчет переадресации?
Нет перенаправления
Мне нравится случай без переадресации, потому что это WYSIWYG (What You See Is What You Get), что означает, что когда страница загружена, URL в браузере начинается с того, что вы набрали в браузере. Это сбивает с толку, если вы набираете URL 'with-www' и он меняется на 'without-www', или наоборот. Мне никогда не нравился компьютер, который автоматически меняет вещи для меня ...
Проверяяя некоторые сайты в интернете, я обнаружил, что только на нескольких сайтах URL, набранный посетителем в браузере, 'with-www' остался 'with-www', а 'without-www' остался 'without-www'. Их не так уж много, так что, наверное, это не самая лучшая идея, почему они все равно решили это сделать, должна быть причина?
С точки зрения SEO (поисковой оптимизации) это, конечно, не лучшее решение. Ваш сайт может иметь записи в базах данных поисковых систем 'with-www' URLs и 'without-www' URLs.
Переадресация на URL ' without-www'.
В этом случае, когда вы вводите URL 'with-www', веб-адрес в вашем браузере меняется на URL 'without-www'. Некоторые примеры сайтов ' without-www':
- twitter.com
- github.com
- stackoverflow.com
Это означает, что некоторые верхние сайты перенаправляются на URL 'without-www'. Он короче, выглядит современно, красивее, в браузере. Это и есть причина, по которой они решили сделать это так?
Переадресация на URL 'with-www'.
В этом случае, когда вы вводите URL 'without-www', веб-адрес в вашем браузере меняется на URL 'with-www'. Некоторые примеры сайтов ' with-www':
- www.nytimes.com
- www.python.org
- www.apple.com
Похоже, что большинство топовых сайтов перенаправляются на URL 'with-www'. Это выглядит старомодно или для этого есть очень веская причина?
Скрытие 'www' в браузере
Недавно популярные браузеры, такие как Chrome и Safari, начали скрывать часть URL 'www' . Объяснение от Google заключается в том, что они 'хотят сделать URL более легким для чтения и понимания, а также удалить отвлекающие факторы', смотрите ссылки ниже.
Но подождите, это, вероятно, означает, что верхние сайты не имеют намерения использовать URL 'without-www', а придерживаются URL 'with-www'. Что здесь происходит?
Почему большинство верхних сайтов перенаправляют URL 'without-www' на URL 'with-www'.
Наконец-то у нас что-то получается. Большинство сайтов перенаправляют URL 'without-www' на URL 'with-www' по одной или нескольким из следующих причин:
Cookies
Для владельцев сайтов наиболее важной причиной является то, что происходит с cookies. Для URL 'with-www' на субдомен cookie отправляется только 'www' .
Для URL 'without-www' адрес cookie является общим для всех субдоменов. Данные cookie отправляются с каждым запросом и ответом, независимо от того, использует субдомен эти данные или нет.
Почему это так важно?
Если у вас есть субдомен static.example.com, в котором хранятся данные images, javascripts и stylesheets, то cookie всегда будет отправляться на этот домен. Хуже всего, если вы используете внешний CDN (Content Delivery Network) на URL типа static.yourdomain.com, то невозможно предотвратить cookie .
Также cookie удерживает данные от посетителя вашего сайта, что означает, что вы создаете проблему конфиденциальности и возможную утечку информации, если вы не предпримете мер по предотвращению этого.
Гибкость, доступность
Есть еще одна причина, и это связано с гибкостью, доступностью. Но это применимо только в том случае, если вы используете DNS-сервис провайдера, у которого вы размещаете свой сайт, см. ссылки ниже.
Настройка DNS-записей и перенаправление веб-сервера
Теперь мы знаем, что у нас всегда должен быть URL 'with-www' для нашего сайта, как это сделать?
Для DNS-записей есть два способа:
A-record и CNAME-record:
Type | Host | Data
-------+------------------+-------------
A | example.org | 192.0.1.2
CNAME | www.example.org | example.org
Или две записи A-record:
Type | Host | Data
-------+------------------+-------------
A | example.org | 192.0.1.2
A | www.example.org | 192.0.1.2
Также мы должны сказать веб-серверу, чтобы он перенаправил URL 'without-www' на URL 'with-www'. Пример переадресации с Nginx есть:
if ($http_host = "example.org") {
rewrite ^ $scheme://www.example.org$request_uri? permanent;
}
Резюме
В заголовке этой статьи говорится, что ваш сайт canonical name должен быть www (или приложение, или что-то в этом роде). Это потому, что вы обычно используете запись CNAME , или запись Canonical Name, чтобы установить поддомен 'www' .
Использование URL-адреса 'with-www' для Вашего веб-сайта позволяет обслуживать статические ресурсы из домена cookieless, что сокращает объем передаваемых данных. Использование URL-адреса 'with-www ' для Вашего веб-сайта также предотвращает возможные проблемы с конфиденциальностью и безопасностью данных о посетителях (cookie).
Ссылки / кредиты
Choosing between www and non-www URLs
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs
Domain IP address for www and non-www for Canonical URL
https://stackoverflow.com/questions/19566856/domain-ip-address-for-www-and-non-www-for-canonical-url
Issue 883038: Feedback: Eliding www/m subdomains
https://bugs.chromium.org/p/chromium/issues/detail?id=883038#c114
To WWW or not WWW
https://www.netlify.com/blog/2017/02/28/to-www-or-not-www/
Why a domain’s root can’t be a CNAME — and other tidbits about the DNS
https://www.freecodecamp.org/news/why-cant-a-domain-s-root-be-a-cname-8cbab38e5f5c/
Оставить комментарий
Комментируйте анонимно или войдите в систему, чтобы прокомментировать.
Комментарии (2)
Оставьте ответ
Ответьте анонимно или войдите в систему, чтобы ответить.
Another brilliant and helpful post. Thanks! Why don't you include an About on your blog? Can't seem to locate it.
Недавний
- Скрытие первичных ключей базы данных UUID вашего веб-приложения
- Don't Repeat Yourself (DRY) с Jinja2
- SQLAlchemy, PostgreSQL, максимальное количество строк для user
- Показать значения в динамических фильтрах SQLAlchemy
- Безопасная передача данных с помощью шифрования Public Key и pyNaCl
- rqlite: альтернатива dist с высокой степенью готовности и SQLite
Большинство просмотренных
- Используя Python pyOpenSSL для проверки SSL-сертификатов, загруженных с хоста
- Использование UUID вместо Integer Autoincrement Primary Keys с SQLAlchemy и MariaDb
- Подключение к службе на хосте Docker из контейнера Docker
- Использование PyInstaller и Cython для создания исполняемого файла Python
- SQLAlchemy: Использование Cascade Deletes для удаления связанных объектов
- Flask Удовлетворительный запрос API проверка параметров запроса с помощью схем Маршмэллоу