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.
I think that www vs. no-www, as a matter of "putting the customer first" is so INCREDIBLY insignificant, compared to the thousands of other decisions that go into a product, that it's ridiculous we're even having this conversation. This is looking for optimization in the wrong places at its finest.
The www serves as a clue that it's a URL. Most people would recognize example.com as a domain even if given no other context. Contrast that with example.design. I think to most, www.example.design would be more recognizable.
> 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.
The article says:
"Should I redirect no-www to www?
Yes.
Redirection ensures that visitors who type in your URL reach you regardless of which form they use, and also ensures that search engines index your canonical URLs properly."
It sucks that this is the state of things, because of the technical infrastructure that's supporting these systems. But it's absolutely not being advocated because it's technically more efficient, because it's cute for branding, because it helps the marketing team collect customer data. It's entirely based on being able to provide the highest level of consistent service to a customer.
Doing it any other way is prioritizing brand over customer.
Uptime and performance is typically some of the most important things for customers. Definitively way more important in general than whether there's a www prefix or not...
I agree. Microsoft, Apple, and Google have the ability to modify user behavior without much downside. The rest of us are better off making the user experience as fast, efficient, and simple as possible.
By coincidence, I just put a 301 redirect on my personal site to go from www.xpda.com to xpda.com two days ago. If I could only get ctrl-enter to submit https://domain.com instead of http://www.domain.com in Firefox, I'd be happy. (There was a bug that prevented this last time I checked.)
Being able to serve your website from a CDN helps the customer: it means the website is up when they want to visit it, and it usually means it's faster for them.
Having static content not get cookies helps the customer: it keeps HTTP traffic down, which means that pages load faster.
Separating cookies between different websites helps the customer: it means that when, inevitably, blog.example.com gets broken into, the customer's account info at www.example.com is not compromised. (Of course, this assumes that you're doing least-privilege between your various websites, but you're already doing that because you care about your customer and don't want to send them a letter about how you lost their personal information.)
Not using a separate top-level domain for static content helps the customer: they know that www.example.com and static.example.com are from the same company they trust, Example Industries, Inc. If you caused their browser to show that it's loading files from "static.excdn.com" or something, they might worry.
The customer isn't personally following the redirect; their browser does, so I'm not sure I understand how the redirect deprioritizes the user. As far as visual clutter goes, get an EV cert, which either supplants or replaces the address bar with something much more useful than a URL:
What!? You saying we can't make absolute rules? We have to consider the context? Horrible person!
On that note.. those minimalist designs are quite hard for older or less tech savvy to understand at times. Not the www part of course but the designs in general. Something to consider when putting the customer first maybe..
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.
The OP could have avoided a lot of confusion if he began his article like this:
> www. is not deprecated for webmasters (but users don't need to type it)
> This page is intended for webmasters who are looking for information about whether or not to use www in their canonical web site URLs; however, the website can still be advertised without the www and the user never needs to type it.
Even in this HackerNews discussion with technically knowledgeable people I see a lot of discussion stemming form this misunderstanding of what the OP is trying to say. (Example: "I should take the toll by typing www every time? life is too short.")
Yeah, this would have helped a lot to avoid discussion. I suppose the author of the website expects mostly webmasters to come and read what he writes. But here are a lot of other people as well. So probably it's not the author who should adopt his text (why should he even know we exist) but the title of the link in HN itself should make it clear.
Well, I agree that users shouldn't need to type it, but it should still be advertised, especially in print.
www makes it immediately obvious that you're looking at a url, which is especially important with gtlds. A line at the bottom that says dog.spa is meaningless. www.dog.spa fixes that with only 4 characters.
You could print http://dog.spa, but now you've added 7 characters and it looks even more technical, which is stupid if the goal of removing www is to simplify things.
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."
Is anyone else really bothered that 2 sites advocating for "best practices" fail to use HTTPS? People are willing to write paragraphs arguing the technical merits of subdomains but nobody could take 10 minutes to put their site behind CloudFlare?
If SRV[1] records had been a thing sooner, we could have had our cake and eaten it, too. SRV records encode the protocol into the DNS entry. If you wanted the HTTP server for example.com, for example, you'd lookup the SRV record for _http._tcp.example.com. You get back the IP and port of the host to connect to.
If you had a hosting provider, you could CNAME _http._tcp.example.com to your hosting provider. Naked domains + CNAME works as expected.
No. The main issue here is cookie control, or, to be exact, the complete lack of one.
You can't tell user-agents "the cookie I set must be valid for example.org and websocket.example.org but no others" (the example is crude and non-scalable, real-world semantics of this must be different), which leads to all sort of problems. Heavier static media requests, mixed cookie state if you use staging.example.org for pre-production environment, inability to provide third parties subdomains for their UGC, etc etc. All can be solved but not really convenient.
Would there be a way to have good control over cookie scoping, a lot of hacks would be gone and www/non-www distinction would be purely cosmetic for most cases. Granted, not all, SRV records are still a good idea.
I'm using a naked domain. The biggest reason why I'm using it is because my domain name as minimalistic as it can get (six characters long, seven if you count the dot) and I sure as hell love saying to people to just type in my alias and add .me at the end.
Although I did not know about these issues, I have to say that the source really didn't give me strong enough arguments to convince me to go through the hassle of making the switch.
With that being said, I opened up a couple of links from the source and I will look through them and see if they'll change my mind.
Yeah, I use a naked domain too because I got a short and nice one, and I like it this way. All this stuff about cookies is a non-argument for me—I don't set any cookies and don't want to. My DNS host does happen to support ALIAS records, and I find the non-technical argument that the www prefix "serves as a gentle reminder that there are other services than the Web on the Internet" kind of silly. I don't host any other services except ssh, and that's just at the naked domain, too. This whole thing is a non-problem for me and all my users...
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".
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.
As PG says, when you're starting out, do things that don't scale.
My advice is don't over optimize _anything_ until you actually need it.
In the early stages a naked domain is a branding decision that looks nicer than old school www, to my eyes, at least.
You can avoid the cookie issue by not using any subdomains and sending all your calls to single sub URIs such as yoursite.com/api/, yoursite.com/blog/
If you're running your own infrastructure on AWS, for example, you can start your scaling efforts simply with load balancers and multiple instances all pointing to your naked domain. That's going to get you pretty far until you're so big that you need geo scaling & distribution.
Then, if you need geo scaling such as Akami or other geo load blanching solutions you can start to redirect your traffic away from the naked domain to www or whatever.
I frequently use naked domains as they "read back" better in every site I use them in, removes visual cruft and requires recalling less character space in customers memories.
Other websites I frequent that uses naked domains include:
I'm surprised tha they really don't redirect. Would be interesting to see how they deal with the problems mentioned. As always there are probably different solutions to the same problem.
Unfortunately, some hosting providers make this very difficult or impossible. I struggled to get this working on a Google Site hosted at a Google Domain using their DNS tools; it seems Google Domains doesn't have a basic "redirect to www" feature. Eventually I gave up and used Dreamhost's nameservers instead; they offer this feature (and its free; you don't need to pay for hosting).
Or, just use a DNS nameserver that can emulate an apex CNAME, if you are that concerned about letting a third-party renumber their servers at the drop of a hat. I know CloudFlare can do this and it's a feature that standalone DNS nameservers should support.
While the original post was not specific to InfoSec, it does beg the question whether there are any security implications to using/not using "www" in your domain names. Does a naked domain pose any risk? No suggestion to this effect can be found in discussions on the topic I can see so far, but it's a good question to ask in case those of us who do prefer naked domains are missing something.
That's good news. I chose no-www because www seemed redundant and have been wondering if it's a problem. Turns out no, unless it's very big, which I don't expect my site to be (niche market, not a web app). It can even be changed later by redirecting no-www to www.
Is this limitation a problem in the design of the domain name system, or something quite natural and necessary?
> If you are using www, then this is no problem; your site’s cookies won’t be sent to the static subdomain (unless you explicitly set them up to do so). If you use the naked domain, the cookies get sent to all subdomains (by recent browsers that implement RFC 6265)
From my understanding, pretty much all browsers DON'T send google.com cookies to subdomains -- they only send .google.com cookies to all subdomains.
This seems backed up by their cited RFC 6265[1]:
> Unless the cookie's attributes indicate otherwise, the cookie is returned only to the origin server (and not, for example, to any subdomains)
[+] [-] feelix|10 years ago|reply
[+] [-] forgotpasswd3x|10 years ago|reply
[+] [-] obelisk_|10 years ago|reply
[+] [-] jlg23|10 years ago|reply
The article says:
"Should I redirect no-www to www?
Yes.
Redirection ensures that visitors who type in your URL reach you regardless of which form they use, and also ensures that search engines index your canonical URLs properly."
[+] [-] lotyrin|10 years ago|reply
[+] [-] glenngillen|10 years ago|reply
Doing it any other way is prioritizing brand over customer.
[+] [-] ma2rten|10 years ago|reply
[+] [-] bobfunk|10 years ago|reply
[+] [-] xpda|10 years ago|reply
By coincidence, I just put a 301 redirect on my personal site to go from www.xpda.com to xpda.com two days ago. If I could only get ctrl-enter to submit https://domain.com instead of http://www.domain.com in Firefox, I'd be happy. (There was a bug that prevented this last time I checked.)
[+] [-] geofft|10 years ago|reply
Being able to serve your website from a CDN helps the customer: it means the website is up when they want to visit it, and it usually means it's faster for them.
Having static content not get cookies helps the customer: it keeps HTTP traffic down, which means that pages load faster.
Separating cookies between different websites helps the customer: it means that when, inevitably, blog.example.com gets broken into, the customer's account info at www.example.com is not compromised. (Of course, this assumes that you're doing least-privilege between your various websites, but you're already doing that because you care about your customer and don't want to send them a letter about how you lost their personal information.)
Not using a separate top-level domain for static content helps the customer: they know that www.example.com and static.example.com are from the same company they trust, Example Industries, Inc. If you caused their browser to show that it's loading files from "static.excdn.com" or something, they might worry.
The customer isn't personally following the redirect; their browser does, so I'm not sure I understand how the redirect deprioritizes the user. As far as visual clutter goes, get an EV cert, which either supplants or replaces the address bar with something much more useful than a URL:
https://www.expeditedssl.com/assets/browser-ssl/extended-val...
[+] [-] WhoBeI|10 years ago|reply
On that note.. those minimalist designs are quite hard for older or less tech savvy to understand at times. Not the www part of course but the designs in general. Something to consider when putting the customer first maybe..
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] Rezo|10 years ago|reply
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.
[+] [-] vasquez|10 years ago|reply
I intentionally break such requests by dropping anything beyond the host name.
If someone are sending data in the open, I don't want their clients to keep working thanks to built-in support for redirects.
[+] [-] cantrevealname|10 years ago|reply
> www. is not deprecated for webmasters (but users don't need to type it)
> This page is intended for webmasters who are looking for information about whether or not to use www in their canonical web site URLs; however, the website can still be advertised without the www and the user never needs to type it.
Even in this HackerNews discussion with technically knowledgeable people I see a lot of discussion stemming form this misunderstanding of what the OP is trying to say. (Example: "I should take the toll by typing www every time? life is too short.")
[+] [-] erikb|10 years ago|reply
[+] [-] clinta|10 years ago|reply
www makes it immediately obvious that you're looking at a url, which is especially important with gtlds. A line at the bottom that says dog.spa is meaningless. www.dog.spa fixes that with only 4 characters.
You could print http://dog.spa, but now you've added 7 characters and it looks even more technical, which is stupid if the goal of removing www is to simplify things.
[+] [-] ludwigvan|10 years ago|reply
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."
[+] [-] marcosdumay|10 years ago|reply
http://no-www.org/
[+] [-] vortico|10 years ago|reply
[+] [-] tinalumfoil|10 years ago|reply
[+] [-] EugeneOZ|10 years ago|reply
P.S., About cookies: Don't use cookies, LocalStorage is much better.
[+] [-] deathanatos|10 years ago|reply
If you had a hosting provider, you could CNAME _http._tcp.example.com to your hosting provider. Naked domains + CNAME works as expected.
(And you can weight records, assign priorities…)
[1]: https://en.wikipedia.org/wiki/SRV_record
[+] [-] drdaeman|10 years ago|reply
You can't tell user-agents "the cookie I set must be valid for example.org and websocket.example.org but no others" (the example is crude and non-scalable, real-world semantics of this must be different), which leads to all sort of problems. Heavier static media requests, mixed cookie state if you use staging.example.org for pre-production environment, inability to provide third parties subdomains for their UGC, etc etc. All can be solved but not really convenient.
Would there be a way to have good control over cookie scoping, a lot of hacks would be gone and www/non-www distinction would be purely cosmetic for most cases. Granted, not all, SRV records are still a good idea.
[+] [-] doublerebel|10 years ago|reply
However, on the wider internet with third party services it's much easier to manage and debug dedicated port numbers.
[+] [-] r3bl|10 years ago|reply
Although I did not know about these issues, I have to say that the source really didn't give me strong enough arguments to convince me to go through the hassle of making the switch.
With that being said, I opened up a couple of links from the source and I will look through them and see if they'll change my mind.
[+] [-] mbrock|10 years ago|reply
[+] [-] akcreek|10 years ago|reply
[+] [-] lowmagnet|10 years ago|reply
I now use the bare version of my name plus .com.
[+] [-] bobfunk|10 years ago|reply
I wrote a post with all the details around why it's best to use www and why naked domains can be really bad for performance and uptime:
https://www.netlify.com/blog/2016/01/12/ddos-attacks-and-dns...
[+] [-] chrisblackwell|10 years ago|reply
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.
[+] [-] developer2|10 years ago|reply
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".
[+] [-] ymse|10 years ago|reply
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.
[+] [-] gavinpc|10 years ago|reply
Edit: the answer is probably http://longbets.org/
[+] [-] jv22222|10 years ago|reply
My advice is don't over optimize _anything_ until you actually need it.
In the early stages a naked domain is a branding decision that looks nicer than old school www, to my eyes, at least.
You can avoid the cookie issue by not using any subdomains and sending all your calls to single sub URIs such as yoursite.com/api/, yoursite.com/blog/
If you're running your own infrastructure on AWS, for example, you can start your scaling efforts simply with load balancers and multiple instances all pointing to your naked domain. That's going to get you pretty far until you're so big that you need geo scaling & distribution.
Then, if you need geo scaling such as Akami or other geo load blanching solutions you can start to redirect your traffic away from the naked domain to www or whatever.
[+] [-] mythz|10 years ago|reply
Other websites I frequent that uses naked domains include:
[+] [-] erikb|10 years ago|reply
[+] [-] tantalor|10 years ago|reply
http://www.yes-www.org/redirection/
Unfortunately, some hosting providers make this very difficult or impossible. I struggled to get this working on a Google Site hosted at a Google Domain using their DNS tools; it seems Google Domains doesn't have a basic "redirect to www" feature. Eventually I gave up and used Dreamhost's nameservers instead; they offer this feature (and its free; you don't need to pay for hosting).
[+] [-] Sami_Lehtinen|10 years ago|reply
[+] [-] deckar01|10 years ago|reply
[+] [-] kmeisthax|10 years ago|reply
[+] [-] spinningarrow|10 years ago|reply
How do GitHub and Twitter for example deal with this? Do they have to go through a lot of hoops in order to not use 'www'?
[+] [-] nailer|10 years ago|reply
[+] [-] christianbryant|10 years ago|reply
[+] [-] robszumski|10 years ago|reply
[+] [-] Spooky23|10 years ago|reply
Imagine being confronted with something.nyc, or something.cool, or something.repair. WTF is it?
That www gives you some context.
[+] [-] djhn|10 years ago|reply
[+] [-] Nutmog|10 years ago|reply
Is this limitation a problem in the design of the domain name system, or something quite natural and necessary?
[+] [-] chrisweekly|10 years ago|reply
[+] [-] lkbm|10 years ago|reply
From my understanding, pretty much all browsers DON'T send google.com cookies to subdomains -- they only send .google.com cookies to all subdomains.
This seems backed up by their cited RFC 6265[1]: > Unless the cookie's attributes indicate otherwise, the cookie is returned only to the origin server (and not, for example, to any subdomains)
Am I just confused?
[1] http://tools.ietf.org/html/rfc6265#section-4.1.2