Вопрос: Какой смысл иметь «www» в URL?


Кроме исторических причин, есть ли причина иметь «www» в URL?

Должен ли я создать постоянную переадресацию из www.xyz.com в xyz.com, или из xyz.com в www.xyz.com? Какой из них вы бы предложили и почему?


219
2018-05-27 08:02


Источник


Связанный: stackoverflow.com/questions/1109356/... - Quintin Par
И наоборот, какой смысл в этом нет. Для целей cookie и поддоменов при успешном присутствии в Интернете полезно выделить несколько процессов. - Fiasco Labs
Этот ответ, хотя и не связаны напрямую, представляется актуальным. - Skippy le Grand Gourou


Ответы:


Одна из причин, по которой вам нужно www или какой-либо другой субдомен связан с причудой DNS и записью CNAME.

Предположим, что для этого примера вы используете большой сайт и заключили договор на CDN (сеть распространения контента), например Akamai. Обычно вы создаете DNS-запись для своего сайта как CNAME для некоторых akamai.com адрес. Это дает CDN возможность предоставить IP-адрес, близкий к браузеру (в географических или сетевых условиях). Если вы использовали запись A на своем сайте, то вы не сможете предложить эту гибкость.

Причуда DNS заключается в том, что если у вас есть запись CNAME для имени хоста, вы не можете любой другой записи для этого же хоста. Однако ваш домен верхнего уровня example.com обычно должны иметь запись NS и SOA. Поэтому вы также не можете добавить запись CNAME для example.com,

Использование www.example.com дает вам возможность использовать CNAME для www который указывает на ваш CDN, оставляя необходимые записи NS и SOA example.com, example.com запись обычно также имеет запись A, указывающую на хост, который будет перенаправлен на www.example.com используя перенаправление HTTP.


192
2018-05-27 08:10



Вы можете предоставить запись CNAME по умолчанию, указывающую на CDN, вам не нужно использовать «www». Это позволяет DNS-серверу иметь SOA, NS, CNAME и т. Д. Все RR для одного и того же имени домена. - Chris S
Почему никто не упоминает ALIAS (или ANAME записей) в этой теме? Не достигает ли он тех же результатов, что и CNAME на nakeddomain (за исключением проблемы с файлом cookie ...)? - Augustin Riedinger
@AugustinRiedinger: записи ANAME не являются стандартными типами DNS RR. Они являются собственностью конкретных поставщиков услуг. - Greg Hewgill
Но создает ли это какую-либо проблему совместимости или что-то еще? Есть ли какая-то причина, по которой мы не должны их использовать (помимо того, что они не являются стандартными, но проприетарными)? - Augustin Riedinger
@AugustinRiedinger не поддерживается в большинстве DNS серверы, Но если ваш поставщик имеет DNS-сервер, который поддерживает эти функции, то это не должно создавать проблем с клиентами. - Koen.


Примечание. Что касается ратификации и реализации (всеми текущими браузерами, кроме возможно, MSIE 11, см. комментарии) RFC 6265 в 2011 году следующее не является более точным, поскольку файлы cookie по умолчанию никогда не устанавливаются в поддоменах.

Исторически, одна хорошая техническая причина для www.example.com каноническим было то, что файлы cookie основного домена (т. example.com) были отправлены во все субдомены.

Поэтому, если ваш сайт использует файлы cookie, они будут отправлены на все его поддомены.

Теперь это часто имеет смысл, но это очень вредно, если вы хотите загружать статические ресурсы, так как он просто тратит полосы пропускания. Рассмотрите все таблицы стилей и изображения на своем веб-сайте: обычно нет причин отправлять файлы cookie на сервер при запросе ресурса изображения.

Поэтому хорошим решением является использование поддомена для статических ресурсов, таких как static.example.com, чтобы сохранить пропускную способность, не отправляя файлы cookie. Оттуда можно загрузить все изображения и другие статические загрузки. Если вы сейчас используете www.example.com для динамического контента это означает, что файлы cookie должны отправляться только www.example.com, а не static.example.com,

Если, однако, example.com это ваш основной сайт, затем файлы cookie будут отправлены на все субдоменам, включая static.example.com,

Теперь это не относится к большинству сайтов, но позже изменение вашего канонического URL-адреса не является хорошей идеей, поэтому, example.com вместо www.*, вы в основном придерживаетесь этого.

Альтернативой является использование совершенно разные URL для статических ресурсов. Например, переполнение стека использует sstatic.net, YouTube использует ytimg.com и т.д. …


98
2018-05-27 08:15



Кстати, мне действительно не нравится www.x как канонический URL, так что лично я, вероятно, использовал бы другой URL-адрес для статических ресурсов, если бы я должен был создать большой сайт. - Konrad Rudolph
@RobinWinslow Но установка блюд на domain=example.com установит cookie в домене apex и на субдоменах, и способ избежать этого - не использовать домен apex для HTTP. Хотя, согласился, другим способом было бы просто не указывать domain при настройке файла cookie. Интересно, изменилось ли это с тех пор, как я написал свой ответ (который предшествует соответствующим RFC 6265!), но я не могу побеспокоить его сейчас. - Konrad Rudolph
Похоже, что поведение, о котором я рассказываю, имело место, по крайней мере, с 2011 года, когда был написан RFC 6265 (скорее как резюме текущего поведения браузера, чем утверждение о том, как они должны работать). К настоящему моменту мы можем предположить, что все браузеры будут следовать за ним. Видеть stackoverflow.com/questions/1062963/... а также bayou.io/draft/cookie.domain.html, Учитывая это, я думаю, что ваш ответ вводит в заблуждение не менее 7 лет, хотя он мог бы иметь были точными в некоторых случаях на момент написания. Не могли бы вы обновить его, чтобы прояснить этот факт? - Robin Winslow
@RobinWinslow Да, сделаю. - Konrad Rudolph
@ KonradRudolph фактически, согласно mxsasha.eu/blog/2014/03/04/definitive-guide-to-cookie-domains, описанное вами нежелательное поведение, возможно, существовало в IE11 в то время, когда сообщение было написано, и может все еще оставаться, что остается самой последней версией Internet Explorer. Это было бы довольно значительным и заслуживающим упоминания, но было бы хорошо сначала проверить это. Я не могу легко проверить, так как я на Ubuntu, но если бы вы могли, это было бы замечательно. - Robin Winslow


www является субдоменом, обычно используемым для веб-сервера в домене вместе с другими для других целей, таких как mail и т. д. В настоящее время парадигма субдомена не нужна; если вы подключитесь к веб-сайту в браузере, вы получите сайт или отправку почты на сервер будет использовать свою почтовую службу.

С помощью www или нет, это вопрос личных предпочтений. Противоположные точки зрения можно найти в http://no-www.org/ а также http://www.yes-www.org/ - однако я считаю, что www не требуется и просто добавляет больше ошибок в URI.

Большинство серверов отправляют один и тот же сайт в любом случае, но не перенаправляют. Для целей SEO выберите один, а затем попросите другого перенаправить на него. Например, некоторый код PHP для этого:

if (preg_match('/www/', $_SERVER['SERVER_NAME'])) {
  header("Location: http://azabani.com{$_SERVER['REQUEST_URI']}");
  exit;
}

Однако некоторые причины, способствующие использованию www субдомен, сделанный другими автоответчиками, тоже велик, например, не отправлять файлы cookie на статические серверы (кредит Конрад Рудольф).


10
2018-05-27 08:11



Выглядит как no-www.org вернулась на припаркованную страницу для продажи, где yes-www.org по-прежнему сильны. Я предполагаю, что это решает. Теперь все используют «www». - hacksalot


Если у вас будут субдомены для других целей (например, блог), вы можете захотеть разделить сайты и иметь www префикс для обычного сайта. Другое дело, что единственная важная вещь - выбрать одну из двух и придерживаться ее (по причинам SEO).


7
2018-05-27 08:06



Я не могу найти ссылку на данный момент, но она также может иметь последствия для одной и той же политики происхождения. - Kobi
Да, это будет, к сожалению. Вы не можете использовать AJAX для www.example.comиз example.com или наоборот, без чего-то вроде JSONP. - Delan Azabani


Это довольно исторически. Когда-то давно мы использовали www.example.com, ftp.example.com, images.example.com, uk.example.com и т. Д., Которые казались логической задачей и обеспечивали простой способ распространения нагрузки между сервера.

В эти дни я бы просто пошел на example.com для основного сайта и перенаправил на него www-версию.

Инструменты Google для веб-мастеров позволяют указать предпочтительный домен, поэтому убедитесь, что вы тоже используете их.

Смотрите также:
https://stackoverflow.com/questions/1109356/www-or-not-www-what-to-choose-as-primary-site-name
https://stackoverflow.com/questions/1884157/to-www-or-not-to-www


7
2018-05-27 08:11





Я бы сделал первый. www соглашение происходит с первых дней HTTP, где www.cmu.edu и cmu.edu были очень вероятны в разных машинах.


6
2018-05-27 08:08



в «ранние дни» вы редко видели запись A для домена - возможно, у нее была запись MX, но у вас редко был хост. - Joe H.


Вот еще одна небольшая перспектива.

Не имея www, есть незначительный недостаток, когда дело доходит до текстовых носителей, будь то печатных или онлайн, и это получает его как веб-адрес. В печати обычно довольно очевидно, что example.com - это веб-адрес, и вы можете добавить стили оформления, чтобы подчеркнуть это. Но простой текст онлайн? Не так просто. Скорее всего, если вы отправляете текстовое сообщение - будь то электронная почта, твит, сообщение Facebook, SMS или что-то еще, - он распознает URL-адрес, начинающийся с http: // или www. но не узнает ни одного из них. Поэтому, чтобы URL-адрес был доступен для кликабельной ссылки, вам нужно либо поместить www. или http: // на передней панели, а второй - на www. короче, менее неудобно смотреть и читать легче.


1
2017-11-24 18:22



http://example.com/ является полностью квалифицированным, тогда как www.example.com не является. Я предпочитаю полностью квалифицированный подход, поскольку он всегда распознаваемый как URL-адрес независимо от того, https://example.uk/ или https://blog.example.eu/ или что-то еще. Это согласуется с указанием протокола безопасного сайта как HTTPS; www.example.com является просто доменом и ничего не говорит о том, какой протокол следует использовать для доступа к нему. - James Haigh