Hacker News Reader

Comment by chrisblackwell | Hacker News Reader

> You should use www because today you have a small web site, and tomorrow you want a big web site. Really big.

So Twitter, Pocket, Github, Trello...are all doing it wrong?

I really don't think this matters more, and I think that the non-www version makes a web address so much more readable.

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".

> 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?

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.

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.

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.

>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.

> 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.

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.

Google are really inconsistent in this:

[typed in] -> [sent to]

maps.google.co.uk -> www.google.co.uk/maps/

www.maps.google.co.uk -> www.google.co.uk/maps/

calendar.google.co.uk -> server not found error

calendar.google.com -> https://calendar.google.com/calendar/...

www.google.co.uk/calendar -> 404 error

www.google.com/calendar -> https://calendar.google.com/calendar/...

google.com/calendar -> https://calendar.google.com/calendar/...

google.co.uk/calendar -> 404 error

But then they probably know that most of their users simply type "google" in the search box and then click on "maps" or whatever ...

It only matters if you intend (or require) to CNAME your main site off to some other DNS name. If you're serving your entire site from S3 for example, you can't just alias yoursite.com to your-bucket.s3.amazonaws.com, but you can CNAME www.yoursite.com and have a small server sitting on yoursite.com sending a 301 redirect for every request.

Github and Twitter are large enough to not care. And if you're using something like Cloudflare, they can just take over your IP address with BGP, no DNS trickery needed.

I've worked a sysadmin for more than 10 years now, and never realized that it's not possible to CNAME the domain root. It's good to keep in mind, but in most cases there are other workarounds.

This is also why "naked domains" set up a whole other domain for static files rather than "static.yoursite.com", to avoid the "top-level" cookie (megacookie?) being sent with every request.

By the way, even the CNAME on root domain is no longer a concern if you are already using AWS. Route 53 has supported CNAME on root domain for quite some time now: https://aws.amazon.com/blogs/aws/root-domain-website-hosting...

It's not a true CNAME, but rather a sort of server-side translator to make it behave as a CNAME while really just returning A/AAAA records. It's more like the 'ALIAS' record.

> I've worked a sysadmin for more than 10 years now, and never realized that it's not possible to CNAME the domain root. It's good to keep in mind, but in most cases there are other workarounds.

The common approach is called CNAME flattening, where you can specify a CNAME at the root and your DNS provider 'flattens' that by resolving the A/AAAA record at the end of the CNAME chain.

e.g. CloudFlare's approach: https://support.cloudflare.com/hc/en-us/articles/200169056-C...

> And if you're using something like Cloudflare, they can just take over your IP address with BGP, no DNS trickery needed.

Why can't Heroku and such say 'put this IP as an A record' and do the same if they have issues with that particular server?

> If you're serving your entire site from S3 for example, you can't just alias yoursite.com to your-bucket.s3.amazonaws.com

You can if you also use Amazon's Route 53 service which can resolve the A record of your naked domain directly to a S3 bucket or CloudFront endpoint. They call it an Alias record: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/res...

Not to mention archive.org. If they don't care about archival URL's, I'm not sure who does.

Edit: the answer is probably http://longbets.org/

Reply on news.ycombinator.com