Comments 31
Однако это вызвало протест пользователей, заявивших о том, что между www-сайтами и m-сайтами есть серьезная разница. В итоге Google отменила автоматическое сокрытие поддоменов.
Ну так www.site в большинстве случаев это просто алиас к site. Никогда не понимал, зачем он сейчас нужен, это архаизм. А m.site вроде как не собираются скрывать.
Он остался с тех времён, когда сервера называли по именам, и у компании могло быть, например, три сервера: один отвечал за www, второй за почту (smtp/pop3) и третий мог обслуживать ftp. Поскольку никаких динамических средств разделения трафика (балансеров, port-based routing и т.д.) не было, использование разных доменных имён позволяло разделить типы трафика по разным серверам.
Сейчас, говоря о каком-то ресурсе с каким-то доменом, мы по умолчанию подразумеваем, что его надо открыть в браузере, поэтому www не нужен и даже вреден.
Т. е. если на сайте есть авторизация пользователя, то www.site.com безопаснее, т. к. к этим кукам больше ни у кого нет доступа, а на site.com доступ есть у всех.
В особо важных случаях вместо www можно также юзать специальный поддомен. Например, Вы видели такой у любого из хостингов, когда заходите в админку. Это сделано не для красоты.
Но в 99% случаев сайт разрабатывается одной командой или человеком, и на поддоменах всё-равно не будет левого кода. И использовать www нет никакого смысла, это только мозолит глаза. Причём нужно понимать, что если вдруг реально понадобится, Вы итак сможете перейти на www в любой момент без каких-либо последствий. Но с 99% вероятностью Вам это так никогда и не понадобится.
Если же сайт большой, и разные разделы сайта разрабатываются разными командами, то да, тут уже всегда использование поддоменов логичнее (для разделения кук, чтобы взлом одного поддомена не влиял на другие). Но даже в этом случае вместо разделения по поддоменам я бы поюзал разделение по разделам, например, site.com/раздел1, site.com/раздел2 и т. д. (это возможно, но надо аккуратно, если Вы не профи, не делайте так, т. к. нужно настроить права в CORS, в фреймах на «on messsage», запретить флеш, запретить прямой доступ к фреймам переопределив стандартное API, убрать window.opener, поставить на всякий случай всем ссылкам
rel="noopener noreferrer" и т. д.).
А к кукам на site.com есть доступ вообще на всех поддоменах.
Это только при некорректной настройке сервера или в забагованном IE11 (в Edge уже пофиксили). Зайдите на тот же www.habr.com — по сравнению с habr.com половина кук (например habrsession_id) будет отсутствовать (другая половина, вроде PHPSESSID, останется, но это уже у Хабра надо спрашивать почему)
Domain=<domain-value> (optional):
Hosts to where the cookie will be sent.
- If omitted, defaults to the host of the current document URL, not including subdomains.
- Contrary to earlier specifications, leading dots in domain names (.example.com) are ignored.
- If a domain is specified, subdomains are always included.
Если мы указываем конкретный домен, то кука будет доступна также и на всех поддоменах. Но когда мы вообще ничего не указываем, кука будет доступна только на текущем домене и больше никаких.
Тогда в использовании www вообще нет никакого смысла.
Кстати, появилась также новая опция SameSite=Strict|Lax|None, которая позволяет запретить посылку куки, когда запрос к сайту посылается с другого домена (например, через fetch, ajax, img
Лучше бы сделали, что если в адресной строке написано 10.17.185.1:8080/тест, и это выделяется и копируется, то в буфере обмена не оказывалось бы http://10.17.185.1:8080/%D1%82%D0%B5%D1%81%D1%82. Простая операция копирования, но добавляет протокол и преобразует не-ASCII символы в urlencoded. :/
добавляет протоколЛогично, потому что в адресной строке у вас, на самом деле, написано
http://10.17.185.1:8080, а не 10.17.185.1:8080. Т.е. никто ничего не добавляет, протокол там есть изначально, вам визуально его не показывают.
Не удобно — но хотя бы так…
Подключился к рабочему компу, проверил. Хром 78.0.3904.70, если что.
Ctrl+A+Ctrl+C– ковёркает буфер обмена. Ожидаемо.End+␣+Ctrl+A+Ctrl+C– тоже ковёркает буфер обмена. Странно.Home+␣+Ctrl+A+Ctrl+C– ковёркает буфер обмена. Хм.End+␣+Shift+Home+Ctrl+C– всё ещё ковёркает буфер обмена. Неужели совет не из той версии хрома?..Home+␣+Shift+End+Ctrl+C– копирует так, как надо! Фух.
Спасибо. Это было сложно, но вы упростили мне жизнь. :)
Да, это логично и в 98% случаев востребованно. Но всё равно неудобно.
Кмк, лучшее решение – не убирать отображение протокола. От того, что там будет написано http:// на широких экранах места не убавится, а копировать нужное будет проще. Оставшиеся два процента приходятся на какие-нибудь интранет-сайты и ftp://, скажем. :)
Но было бы круто, чтобы появлялась кнопка «скопировать как текст» которая копирует отображаемый адрес без всяких преобразований. После первого копирования объяснить, как это работает, и что ссылка не обязана быть рабочей.
Также рядом можно добавить кнопку «скопировать адрес страницы». Если юзер хочет скопировать адрес для себя, он нажмёт первую кнопку. Если для постинга где-то, то вторую.
Надеюсь, убрав http(s), они не запилят через десяток версий в результатах поиска новые модные ссылки аля amp://habr.com, которые будут отображаться как habr.com.
Хром скоро страницы начнет обрезать, т.к. «ну а че, нах оно нужно».
UPD: Включаем Temporarily unexpire M76 flags, появляются опции Omnibox UI Hide Steay-State URL. Но они не переключаются. Просто ничего не меняется после рестарта браузера :)
Google избавился от www в адресной строке в версии Chrome 79