Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Flaw to using non-www domain a canonical?

I love the idea of short, clean urls like example.com over www.example.com, and certainly whichever one is used should redirect to the other. However, as I have researched the matter over time, I've come to the conclusion that using the non-www url as the canonical url is a liability if it ever comes time to host static content on a separate domain without increasing the transfer size with cookies.

Non-www domain shares it's cookies with all subdomains

In other words, if http://example.com is your canonical url, then it will very likely include cookies. Due to the way that cookies get set, those cookies will be shared with all subdomains, like users.example.com, dev.example.com, www.example.com, and most importantly, images.example.com or files.example.com.

Thus, if you want to serve static file content from a separate subdomain, you'll end up bundling cookies from the main site with them, and increasing the transfer size of the http request.

In which case to prevent passing cookies with the static content, you'd need to buy a completely separate url (e.g. examplefiles.com).

www domain keeps it's cookies compartmentalized

Conversely, if you set www.example.com as the canonical url, I believe the cookie only applies to that www. site, and not to any other subdomains. In that case, you save yourself the need to buy and maintain a second url to avoid serving cookies with your static content, you just make sure that files.example.com or images.example.com or the like is configured to -not- serve cookies.

Any mitigating factors?

Is this analysis correct? Doesn't this problem make use of a short, non-www url as your canonical url slightly non-future-proof, in this small, but potentially important-down-the-line way? Are there other mitigating factors that I am missing, like a method to ensure that the cookie is only set for the canonical non-www short url?

share|improve this question
    
Apart from the technical errors, you have made invalid assumptions. e.g. "then it will very likely include cookies". The use of cookies has absolutely nothing to do with whether or not the site uses or requires the www subdomain, nor does their implementation. –  John Gardeniers May 3 '11 at 22:27
    
That is true. I guess what I meant was: If you use example.com as your canonical url, and you use cookies, then the cookie will be set to use example.com as it's base. Which I will rephrase. Certainly this isn't a problem for sites that don't use cookies at all, and won't ever use cookies in the future. –  Kzqai May 3 '11 at 22:46
add comment

2 Answers

up vote 2 down vote accepted

I don't really see it as a problem, as cookies aren't that big and the server doesn't have to send them back in the response. So while yes, one or more cookies set by example.com will "balloon" the request to static.example.com, static.example.com doesn't have to send it back in the response, so the server's response is completely unaffected.

Further, if you have content that you know to be static (images, CSS, JS, etc.), you should be setting proper cache control headers, especially an Expires header for some appropriate time in the future (e.g. +1 day, +1 week, +50 years, whatever makes sense for how often your static content changes). With this done, those cookies will only be sent one time, and then future need for those files will be handled by the browser's cache.

If you do still feel like this is too much (I can't really see how it could be, honestly), you can possibly mitigate it by using paths. For example, if your web app only needs cookies at example.com/app, set the cookie-path to be /app, and then requests to static.example.com/images/some-awesome-image.jpg won't send that cookie because the path doesn't match.

You can further mitigate it by reducing the number of cookies you use -- for most purposes, one (and only one) cookie storing a single session ID only adds a few bytes (less than 1KB in every implementation I've seen/used), and gives the server ample information to look up everything it needs to know about that client server-side.

Honestly, if you're worried about short-URL domains making your site non-future-proof because of cookies, then I think you have an architectural problem with too many/too big cookies, and you should re-evaluate your strategy from that point of view.

share|improve this answer
    
Fair enough, that sounds about right. –  Kzqai May 4 '11 at 15:24
    
@Kromey, am I right to say even with all proper headers set, nothing we can do can stop the fact that one or more cookies set by example.com will "balloon" the request to static.example.com? If so, doesn't that "hurt" the server which handles requests on static.example.com ? –  Pacerier Sep 20 '11 at 12:35
    
@Pacerier Correct, cookies set by example.com will be sent to static.example.com as well. I don't believe it hurts anything, though -- it's such a small amount of data, and if static.example.com isn't doing anything with the cookies anyway it's just ignored. Your server probably sees far more traffic from script kiddies trying to hack into your SSH server, and other Internet background noise, than it sees in cookies "ballooning" requests. –  Kromey Sep 20 '11 at 18:53
    
@Kromey ic. thanks for the confirmation. My point is simply 0.000001 is not the same as 0. 0 is wonderful, multiply it by 10e500 and it's still 0. –  Pacerier Sep 21 '11 at 15:04
    
@Pacerier Mathematically speaking you're right; realistically speaking, however, I don't believe a cookie or three is going to have any impact whatsoever on server performance. Maybe 9,999 requests instead of an even 10k -- not a meaningful impact at all, and one that is easily dwarfed by simple statistical variation. –  Kromey Sep 21 '11 at 16:56
show 3 more comments

Yep, your analysis is correct. Of course, you can always drop down a hefty $10/year on a separate domain, and use whatever canonical domain name you want to use.

share|improve this answer
1  
I don't really see the cost of another domain as the biggest issue, more like the maintenance & monitoring of another domain. Certainly it's not a major difference, but it's one I'm trying to quantify. –  Kzqai May 4 '11 at 15:26
    
"Hefty $10/year" was a bit of friendly sarcasm. However, sometimes the trouble telling your developers to update all their code (to switch the canonical domain) requires more effort than a separate domain. –  Matt Beckman May 4 '11 at 16:45
    
If you have SSL as well, and don't want to see the "mixed secure and nonsecure items" warning, it means 2 SSL certificates. So, it is not only $10. –  Milan Babuškov Apr 8 '13 at 20:45
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.