4 ms·

The advice being given by the OP is outdated. The only relevant point is the CNAME for load balancing which, unless you are on AWS which permits CNAMEs on root

The advice being given by the OP is outdated. The only relevant point is the CNAME for load balancing which, unless you are on AWS which permits CNAMEs on root domains, can be a restriction. Everything else is advice from someone who still thinks it's 1995. The norm now is for naked domains. www is a concept that has vanished from the "real world" that most of us live in here in 2016. It's natural to hang onto things that you grew up with, and the "I should use www" is one of those things. It used to be the norm. This is no longer the case, and there are few arguments to support keeping it other than "it's what I originally learned to use".

wfunction 11y ago
> The advice being given by the OP is outdated. The only relevant point is the CNAME for load balancing > Everything else is advice from someone who still thinks it's 1995 What about the part about cookies and static content? Why do you consider that inapplicable nowadays?
- developer2 11y ago
  Cookies are broken down into two possible situations: 1. Serving of static content from a CDN on a separate hostname than the web servers. First of all, 99% of companies do not fall under the umbrella where saving the few bytes of the cookie request header is going to save you many Mbps/Gbps/packets of bandwidth. For most of us, having our example.com cookies unnecessarily sent to static.example.com isn't a big deal. Secondly, this is remedied by using a separate domain name for your CDN rather than a subdomain. Example: Facebook uses fbcdn.net rather than a subdomain on facebook.com - even though they do still use the www prefix. 2. You want separate "sections" to your website, akin to Google's mail.google.com, news.google.com, images.google.com, maps.google.com, etc. Maybe you want the cookies for your root domain to only be sent to that root domain and not all your subdomains. This is not completely ignorable, but I have personally not seen a situation where cookies on the root domain or www cannot/should not be able to be shared across subdomains. I just find it odd that www is still considered a convention by some. If you're redirecting the root to www anyway, there is no reason to use www. You may as well use hi.example.com as your primary domain and just redirect example.com to hi.example.com. www has no intrinsic meaning, it's just a regular subdomain with DNS records like any other subdomain.
snowwrestler 11y ago
Boy, I hope someone informs Amazon, Apple, Google, Facebook, and Microsoft that it's not 1995 anymore--they're still using www. But, I guess those are more like "old man" companies, not cool new 2016 companies like AirBnB, Uber, and Snapchat. Oh wait, they use www too.
- developer2 11y ago
  The thing is, www prefix was never a requirement. It came about as a convention to very specifically indicate that www.example.com = web server, and ftp.example.com = ftp server, etc. There's no real reason to do it, other than convention from the early days. The CNAME restriction is really the only technical gotcha, and this is slowly becoming a non-issue with DNS services like Route 53 that now allow CNAME on roots.
  - pbhjpbhj 11y ago
    >There's no real reason to do it, other than convention from the early days. // It wasn't convention it was that the naked domain wasn't assumed to have web content as not all domains had web servers on them. If you're used to gophering in to balrog.example.com then a www probably was required to get a browser to reach the www pages. Supposing VR takes off and people have a VR space as their primary internet presence then we might be having the conversation as to why do we both with the vr. subdomain on all the URLs.
    - tdkl 11y ago
      > If you're used to gophering in to balrog.example.com then a www probably was required to get a browser to reach the www pages. Wouldn't the protocol before the domain handle that ? Same goes for ftp etc.
      - clinta 11y ago
        The protocol only tells your computer which program and protocol should be used to communicate with the server. The server server name itself is the destination. If you tell your ftp client to connect to ftp://www.example.com it's going to try and connect to the IP address returned by an A lookup to www.example.com. It has no way of knowing you actually want the IP returned by an A query to ftp.example.com. SRV records could clean this all up, but there seems to be stubborn resistance by web browsers against doing srv lookups.

wfunction 11y ago

> The advice being given by the OP is outdated. The only relevant point is the CNAME for load balancing > Everything else is advice from someone who still thinks it's 1995 What about the part about cookies and static content? Why do you consider that inapplicable nowadays?

developer2 11y ago
Cookies are broken down into two possible situations: 1. Serving of static content from a CDN on a separate hostname than the web servers. First of all, 99% of companies do not fall under the umbrella where saving the few bytes of the cookie request header is going to save you many Mbps/Gbps/packets of bandwidth. For most of us, having our example.com cookies unnecessarily sent to static.example.com isn't a big deal. Secondly, this is remedied by using a separate domain name for your CDN rather than a subdomain. Example: Facebook uses fbcdn.net rather than a subdomain on facebook.com - even though they do still use the www prefix. 2. You want separate "sections" to your website, akin to Google's mail.google.com, news.google.com, images.google.com, maps.google.com, etc. Maybe you want the cookies for your root domain to only be sent to that root domain and not all your subdomains. This is not completely ignorable, but I have personally not seen a situation where cookies on the root domain or www cannot/should not be able to be shared across subdomains. I just find it odd that www is still considered a convention by some. If you're redirecting the root to www anyway, there is no reason to use www. You may as well use hi.example.com as your primary domain and just redirect example.com to hi.example.com. www has no intrinsic meaning, it's just a regular subdomain with DNS records like any other subdomain.

snowwrestler 11y ago

Boy, I hope someone informs Amazon, Apple, Google, Facebook, and Microsoft that it's not 1995 anymore--they're still using www. But, I guess those are more like "old man" companies, not cool new 2016 companies like AirBnB, Uber, and Snapchat. Oh wait, they use www too.

developer2 11y ago
The thing is, www prefix was never a requirement. It came about as a convention to very specifically indicate that www.example.com = web server, and ftp.example.com = ftp server, etc. There's no real reason to do it, other than convention from the early days. The CNAME restriction is really the only technical gotcha, and this is slowly becoming a non-issue with DNS services like Route 53 that now allow CNAME on roots.
- pbhjpbhj 11y ago
  >There's no real reason to do it, other than convention from the early days. // It wasn't convention it was that the naked domain wasn't assumed to have web content as not all domains had web servers on them. If you're used to gophering in to balrog.example.com then a www probably was required to get a browser to reach the www pages. Supposing VR takes off and people have a VR space as their primary internet presence then we might be having the conversation as to why do we both with the vr. subdomain on all the URLs.
  - tdkl 11y ago
    > If you're used to gophering in to balrog.example.com then a www probably was required to get a browser to reach the www pages. Wouldn't the protocol before the domain handle that ? Same goes for ftp etc.
    - clinta 11y ago
      The protocol only tells your computer which program and protocol should be used to communicate with the server. The server server name itself is the destination. If you tell your ftp client to connect to ftp://www.example.com it's going to try and connect to the IP address returned by an A lookup to www.example.com. It has no way of knowing you actually want the IP returned by an A query to ftp.example.com. SRV records could clean this all up, but there seems to be stubborn resistance by web browsers against doing srv lookups.