我喜欢在www.example.com上使用像example.com这样简洁，干净的URL，当然，无论使用哪一个，都应该redirect到另一个。 但是，随着时间的推移我研究了这个问题，我得出的结论是，如果在不增加传输大小的情况下将非静态内容托pipe在单独的域上，那么使用非www url作为规范的url是一个负担与cookies。
换句话说，如果http://example.com是您的规范url，那么它很可能会包含cookie。 由于cookie设置的方式，这些cookie将与所有子域共享，例如users.example.com，dev.example.com，www.example.com，最重要的是，images.example.com或files.example .COM。
因此，如果您想从一个单独的子域提供静态文件内容，则最终将与主站点一起捆绑cookie，并增加http请求的传输大小。
在这种情况下，为了防止将静态内容传递给cookie，您需要购买完全独立的url（例如examplefiles.com）。
相反，如果您将www.example.com设置为规范url，我相信该cookie只适用于该www。 网站，而不是任何其他子域名。 在这种情况下，您可以节省自己购买和维护第二个url的需求，避免向您的静态内容提供Cookie，您只需确保将files.example.com或images.example.com等configuration为-not-提供cookies。
这个分析是否正确？ 这个问题是不是使用了一个简短的，非www的url作为你的规范url，这个规范性的url在这个小的，但是可能非常重要的下线方法中是微不足保证的呢？ 是否有其他缓解因素，我缺less一个方法，以确保cookie只设置为规范非www短url？
我真的不认为这是一个问题，因为cookies不是那么大，服务器也不必将它们发送回来。 所以当然，由example.com设置的一个或多个cookie会将请求“膨胀”到static.example.com，static.example.com不必在响应中发回，所以服务器的响应完全不受影响。
另外，如果你有静态的内容（图片，CSS，JS等），你应该设置适当的caching控制标题，尤其是在将来某个适当的时间（例如+1天，+ 1周，+ 50年，无论您的静态内容多久变化一次）。 完成后，这些cookie将只被发送一次，然后将来需要这些文件将被浏览器的caching处理。
如果你仍然觉得这太过分了（我真的不明白怎么可能），你可以通过使用path来缓解它。 例如，如果您的networking应用只需在example.com/app上使用cookie，请将cookiepath设置为/ app，然后请求static.example.com/images/some-awesome-image.jpg将不会发送那个cookie因为path不匹配。
您可以通过减less您使用的cookie的数量进一步缓解它 – 对于大多数用途而言，存储单个会话ID的一个（且只有一个）cookie只会添加几个字节（在我看过/使用的每个实现中都less于1KB）并为服务器提供足够的信息来查找需要了解的有关该客户端服务器端的所有信息。
老实说，如果您担心短url域名使得您的网站因cookies不能满足未来需求，那么我认为您的cookies存在太多/太大的架构问题，您应该从中重新评估您的策略观点看法。
是的，你的分析是正确的。 当然，你总是可以在一个单独的域名上下注10美元/年，并使用你想要使用的任何规范的域名。