互联网与文化yes-www.org
为什么要使用 www？
Why use www?
2014 — 2016，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章主张网站应使用 www 子域名作为规范地址，列举了裸域名在 DNS（无法用 CNAME）、Cookie 泄漏到子域、CDN/根域解析等方面的技术限制。文中也澄清：这是给站长看的建议，用户并不需要手动输入 www。
为什么经久不衰：域名与 Cookie、CDN、子域安全之间的取舍是长期存在的工程问题，这篇文章把正反两方的论据集中在一起，至今仍是讨论该话题的经典参考。
HN 评论精选
IE 不尊重 Cookie 域限制，会把裸域的会话 Cookie 泄漏给子域上的第三方托管服务，这是使用 www 最有说服力的安全理由。
我以前出于美观强烈反对 www，后来改变了看法。CNAME 论点已过时（DNS 服务商现在支持 ALIAS 记录），静态资源无 Cookie 的论点也不重要（可以放到完全独立的域名，如 fbcdn.net）。但如果要在子域上运行托管服务，就有严重的安全问题：比如 Zendesk 挂在 support.mysite.com 上，你不希望 mysite.com 的会话 Cookie 泄漏给它。大多数浏览器可以指定 Cookie 域来避免，但所有版本的 IE 都不遵守这一点，IE 用户会始终把会话 Cookie 泄漏给子域上的托管服务，这对任何注重安全的站点都不可接受，而且几乎无法绕过。解决办法：一开始就用 www（或任意子域），省得以后迁移头疼。
adrianmacneil查看英文原文
I used to be strongly in the no-www camp for aesthetic reasons, but have since come around. There are legitimate reasons why having www (or any subdomain) is important in any large site. The CNAME argument is obsolete since most DNS providers support ALIAS records now. The static no-cookie argument doesn't really matter since you could always serve static content on a separate domain altogether (ex: fbcdn.net). However, if you want to run hosted services on subdomains, you run into an important security issue. For example, say you have Zendesk hosted on support.mysite.com. You don't want to leak session cookies from mysite.com to support.mysite.com. In most browsers, you can just specify the cookie domain and it will only be sent to the root domain. However, NO versions of IE respect this (even IE 10+) [1]. So your IE users will always leak session cookies to hosted services on subdomains. In any reasonably secure site, this is unacceptable (especially when you start using other hosted services for status.mysite.com, careers.mysite.com, etc etc). Unfortunately, this is pretty much impossible to work around, unless you want to ban IE users from using your site entirely. Solution: Just use www (or any other subdomain, if you want to be different) from the start, and save yourself the headache of migrating later. [1] http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/wininet-ie-cookie-internals-faq.aspx
文章关于裸域 Cookie 会泄漏到所有子域的说法有误：默认的 host-only Cookie 并不会发送到子域。
我对文中关于 Cookie 的说法感到困惑。我有裸域 foo.com 和静态域 static.foo.com，配置路径为 / 时，foo.com 的 Cookie 并不会发送到 static.foo.com（在开发者工具的网络面板里可以看到）。而 Google Analytics 这类把域显式设为 .foo.com 的 Cookie 则会被发送。后来弄明白了：未显式设置域的 Cookie 默认是 host-only，只发给 foo.com 本身，不会发给子域；而第三方 Cookie（如 GA）必须指定域名，不是 host-only，所以会发到静态子域。因此文章中“裸域的 Cookie 会发给所有子域”的说法不准确，应改为“非 host-only 且显式设置了域的 Cookie 才会发给所有子域”。
ludwigvan查看英文原文
I'm perplexed by the cookie claim. I have a naked domain (foo.com), and a static domain with the same domain name. (static.foo.com) and the cookies of foo.com are not being sent to static.foo.com if the path is configured as /. (I can see that cookies are not sent from the dev tools' network tab. The cookies for google analytics, which set the domain to .foo.com as opposed to foo.com are being sent to the static subdomain though.) Could someone enlighten me on this? Seems like the article might be spreading misinformation. Edit: Seems like the issue is "host only cookies" are just sent to foo.com, not to static.foo.com A cookie, unless the domain is explicitly set is already host-only. So you will see that if you set up a naked domain, cookies you set for authentication will probably not be sent to subdomain by default. The third party cookies on your application, like Google Analytics on the other hand, have to have specified a domain name and are not host only, so you will see your Google Analytics cookie being sent to the static subdomain. So, this statement from the article seems to be wrong: "If you use the naked domain, the cookies get sent to all subdomains (by recent browsers that implement RFC 6265), slowing down access to static content, and possibly causing caching to not work properly." It should be "If you use the naked domain, the cookies which are not host-only and have domain set get sent to all subdomains (by recent browsers that implement RFC 6265), slowing down access to static content, and possibly causing caching to not work properly."
HTTP/HTTPS 与 www/裸域组合出四种地址，必须全部正确处理并统一重定向到一个规范域名，否则 OAuth 等服务会静默失败。
别忘了 HTTP 与 HTTPS 又增加了一个必须考虑的维度，我前几天就栽在这上面。我的站点在 example.com（裸域），www 有 CNAME，且只提供 HTTPS 服务，http 都重定向到 https://example.com。后来有用户反馈 Google 登录失效，原来有些用户手动输入 https://www.example.com，被 Nginx 的 default_server 接住，站点看起来正常，但 Google OAuth 校验授权来源时发现是 www.example.com 而非 example.com，于是静默失败。总结：如果默认重定向到 HTTPS，务必检查 [www, 裸域] × [http, https] 四种组合都能正确工作，只重定向到一个规范域名，并保留重定向后的路径参数。
Rezo查看英文原文
Remember that HTTP vs HTTPS adds yet another dimension you have to take into account. This bit me the other day. I run a site at example.com (I prefer a naked domain, for no technical reasons whatsoever), with a CNAME record for the www subdomain. But I only want to serve the site over HTTPS. So http://example.com redirects to https://example.com, as does http://www.example.com. Simple enough, right? I however started receiving some spurious reports that the Google Account login option wasn't working on the site, which was quite puzzling at first. Turns out, some users were manually entering https://www.example.com as the address (it's not indexed or linked to anywhere in this form that I could find), which was being handled by the Nginx default_server directive on port 443, causing the site itself to appear to work just fine at https://www.example.com as well. But the Google OAuth service checks the authorized origins for any client side requests, saw www.example.com and was expecting example.com so simply failed silently. Doh! TLDR summary: If you redirect to HTTPS by default, check that all 4 options ([www, naked] * [http, https]) work correctly, and that all redirect just ONE canonical name to keep things sane. And make sure the 3 redirects preserve any request URI parts after the domain as well.
文章的理由都是服务端的技术考量，但从用户体验出发，www 是多余的视觉杂乱和额外重定向。
这些理由都是站在托管方角度的技术问题。任何面向客户的业务都应把客户放在第一位。我可以列出两百个让用户注册邮箱才能购买的理由，但以客户为先的话，不强制注册往往体验更好。域名前加 www 增加了不必要的视觉杂乱，从用户角度看还多了一次重定向。很多网站处处追求极简风格，效果很好；为了技术原因保留 www，就是在这些场景里把用户放在第二位。
feelix查看英文原文
This reasoning is all based on valid, but technical issues for the hosting side. A general rule for any customer-facing business is to put the customer first. I could list 200 different reasons why you should make the customer register an account with their email address before they can purchase something for you. However, if you put the customer first, in many cases it is easier for them if they don't have to do that. Having the www before the domain name adds unnecessary visual clutter and from the customers point of view, an unnecessary redirect before they can get to your site. A lot of sites use minimalist style everywhere, and it's great. Having the www there for technical reasons is putting the user second in those cases.
历次讨论
同类还值得读
如今电脑上几乎所有操作在感知上都比 1983 年更慢（2017）
Almost everything on computers is perceptually slower than it was in 1983 (2017)
2017 年的推文串认为，尽管计算机硬件比 1983 年快得多，日常操作的感知速度却常常更慢：启动、界面响应和网络应用被层层抽象、动画、后台检查与网络依赖拖累。
互联网与文化上首页 5 次 · 2017–2020twitter.com网站肥胖危机
The Website Obesity Crisis
Maciej Cegłowski（idlewords）的经典演讲文稿《网站肥胖症危机》，批评现代网页越来越臃肿：动辄数 MB 的 JavaScript、追踪脚本和广告，把本可以轻…
互联网与文化上首页 5 次 · 2016–2021idlewords.com编辑精选亚马逊那本标价 23,698,655.93 美元的苍蝇书
Amazon’s $23,698,655.93 book about flies
博文讲的是亚马逊上一本关于果蝇的二手书被标到 23,698,655.93 美元。
互联网与文化上首页 5 次 · 2011–2022michaeleisen.org浏览器 User-Agent 字符串的历史
History of the browser user-agent string (2008)
2008 年的经典文章用戏谑的“创世纪”口吻，讲述浏览器 User-Agent 字符串如何从简单的标识演变成层层叠加的伪装：浏览器为了绕过按 UA 分发的网站检测，纷纷把自己伪装…
互联网与文化上首页 5 次 · 2012–2022webaim.org编辑精选最后的问题——艾萨克·阿西莫夫
The Last Question - Isaac Asimov
阿西莫夫最著名的短篇科幻小说《最后的问题》的在线全文。
互联网与文化上首页 5 次 · 2009–2019multivax.com编辑精选