14 ms·

Why use www?

601 points by wfunction 11y ago

Nutmog 11y ago
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?
- vacri 11y ago
  Regarding defunctness, there's nothing magical about the 'www' string - it can be anything, as long as it's not the DNS zone apex (~='base domain'). There are limitations on what you can do with the zone apex entry (such as no CNAMEing it), but no limitations on other entries. 'www' is just convention. As to your question, it's a bit of both. I'm not a network admin, though, so I'll let someone a bit more skilled pipe up. I have run into difficulties with migrating 'bare domains' in a small business environment due to these limitations, though. Not insurmountable, but required more work to cover the issues. Of course, when you're 'big', you'll be dealing with these kinds of issues a lot more.
- yrro 11y ago
  I can't for the life of me figure out why web browsers don't yet do a query for an SRV record named _http._tcp.example.com when the user browses to example.com.
  - colanderman 11y ago
    There are old open bugs for this against most major browsers. See e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=14328 https://bugzilla.mozilla.org/show_bug.cgi?id=14328 For me, this would allow me to have domain names that point to various HTTP/HTTPS based services behind my single outward-facing IPv4 address. As-is, I have to memorize what non-standard ports they're on.
    - Sanddancer 11y ago
      Why not just use a reverse proxy and virtualhost entries? A straightforward proxy will take care of the hostnames, and SNI will handle https.
      - colanderman 11y ago
        The servers are located in different parts of the continent, and the only one that is capable of acting as a proxy has metered bandwidth, while one is interactive and another is a media server. I suppose I could set up a system of HTTP redirects but combined with HTTPS I feel that will get hairy quickly. The service-level redirection SRV records provide are really exactly match my needs.
  - merbpoll 11y ago
    This came up again during http2. The browser vendors just aren't willing to take on the extra latency at the start of the request.
    - deleted 11y ago
      [deleted]
    - zrm 11y ago
      Where is the extra latency? You can do DNS queries for example.com and _http._tcp.example.com concurrently so that you get both answers in the time of one round trip to the DNS server. If there actually is a SRV record and the target isn't locally cached then you would need to do another query, but that is faster than establishing an HTTP session with example.com, getting the 301 redirect and then having to do the query anyway.
      - merbpoll 11y ago
        They didn't want to wait for multiple queries to finish. If you're interested in a detailed rationale you can take a look through the mailing list archives (though it'll be frustrating reading).
        spc476 11y ago
        And that's because the major DNS servers don't bother with answering more than one question per query. Nothing in the DNS specification limits the number of questions to one. The only down side might be that the response to multiple questions might not fit in the standard UDP DNS packet.
        merbpoll 11y ago
        DNS servers can't answer more than one question per query because NXDOMAIN is signalled in the message header and so when QDCOUNT is greater than one the response becomes ambiguous.
nailer 11y ago
Previously: https://news.ycombinator.com/item?id=7961415 https://news.ycombinator.com/item?id=7961415
tantalor 11y ago
See also these directions for redirecting naked domain to www, http://www.yes-www.org/redirection/ 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 11y ago
  wwwizer - http://wwwizer.com/naked-domain-redirect http://wwwizer.com/naked-domain-redirect
- deckar01 11y ago
  I guess they don't provide DNS ALIAS records. I normally see subdomain redirects implemented as an HTTP 301 redirect in the server configuration.
r3bl 11y ago
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.
- akcreek 11y ago
  301 redirect the naked domain to the www and you can keep telling people the same thing - they will be redirected to the www version seamlessly.
  - clessg 11y ago
    You can do that, but the redirect will affect initial load times. Might be worth it, might not be.
- mbrock 11y ago
  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...
- lowmagnet 11y ago
  I used to host at lowmag.net (my old username, still used in places like hn for laziness puposes) I now use the bare version of my name plus .com.
Palomides 11y ago
you don't need to do a mod_rewrite thing, btw, just do: <VirtualHost *:80> ServerName whatever.com Redirect permanent / http://www.whatever.com/ </VirtualHost>
- envy2 11y ago
  Honestly, if you're running on a simple Apache config, you almost certainly don't need to worry about any of the technical issues the article raises.
  - hueving 11y ago
    If your service requires scaling because it's expensive dynamic content, then apache could easily be fast enough and not the bottleneck requiring a switch to something else. It doesn't matter if nginx/whatever can handle 1000+ reqs/sec if your app consumes 300MB of ram per request and takes 1 second to process.
- perlgeek 11y ago
  That either doesn't redirect "deep" links, or it redirects them to the start page.
  - walod 11y ago
    Got any proof of a case where this happens? I'm using it to redirect to https:// https:// and it redirects deep links to the right deep links, and nothing goes to the home page
  - Palomides 11y ago
    I'm running it on my personal site and all links work as intended
CrowFly 11y ago
And, while we're on this topic, news.x.x should be for services using the NNTP.
feelix 11y ago
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.
- deleted 11y ago
  [deleted]
- jlg23 11y ago
  > 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."
  - id 11y ago
    What is your point? I mean, everything the parent wrote still applies.
    - Klinky 11y ago
      For very little effort you can simply redirect your main domain, and gain the technical benefits/simplicity of having a www subdomain, all while not inconveniencing your users. This pretty much makes the parent's point of hosting actual content on the main domain for customer convenience moot.
    - deleted 11y ago
      [deleted]
mattiemass 11y ago
Welp, stupidly I dropped the www with zero research because I saw others do it. Love the explanation of why keeping the www is useful.
- brianwawok 11y ago
  I did too. Then I wanted to host a webpage out of google cloud drive. Opps, doesn't support naked domains. Back to www in the future.
bobfunk 11y ago
We also strongly discourage users from using naked domains, unless they have a DNS host that supports ALIAS records or CNAME flattening. 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-records https://www.netlify.com/blog/2016/01/12/ddos-attacks-and-dns...
- tamana 11y ago
  Your post is grey, light-weight text, which is two reason people won't read it.
  - megablast 11y ago
    And the background isn't even white. Come on!
    - switch007 11y ago
      And "font-weight: 300", naturally. Argh!
marcosdumay 11y ago
Well, the obligatory counterpart: http://no-www.org/ http://no-www.org/
- EugeneOZ 11y ago
  "Technical part" is not as convincing. P.S., About cookies: Don't use cookies, LocalStorage is much better.
  - michaelmior 11y ago
    > Don't use cookies, LocalStorage is much better. Source? Not saying I agree or disagree, but a statement like that without any supporting arguments or discussion isn't particularly helpful.
    - EugeneOZ 11y ago
      Have you tried to find something? Let me help you: http://caniuse.com/#feat=namevalue-storage http://caniuse.com/#feat=namevalue-storage http://stackoverflow.com/a/3220802/680786 http://stackoverflow.com/a/3220802/680786 In short: LocalStorage is supported by all browsers, has no security issues as cookies have, has much bigger storage limit, much more handy API and don't need to be send on each request.
  - tiglionabbit 11y ago
    It doesn't accomplish the same thing. Cookies are added to every web request, while you have to supply your localstorage values manually if you want to use them. At the least, this requires JavaScript. It's also impossible to do for regular clicks on links and when loading images and scripts. Sometimes you want to authenticate those too.
    - EugeneOZ 11y ago
      Ok, I'll rephrase: only use cookies when you want to send them with requests to static files. But don't forget - you will not be able to use CDN in this case.
Smudge 11y ago
yes-www is clearly the more practical solution based on current technology and its limitations. And no-www (http://no-www.org/ http://no-www.org/) is clearly the more aesthetic solution. Either is perfectly valid, and depending on who you ask you'll get reasonable arguments in favor of both. That said, neither choice will ultimately make any difference. Period. Even if your site becomes the next Google, the minor hurdles of a no-www domain vs the technical advantages of a yes-www domain will not make an ounce of difference. Anyone who tells you otherwise is straight up fooling themselves.
hartator 11y ago
Your users won't save 4 chars...
robot 11y ago
whichever the reasons, I should take the toll by typing www every time? life is too short.
- mastazi 11y ago
  No you shouldn't, the article suggests server-side redirection so you don't have to type www in front of the url. Many of the highest-traffic websites already do that, Twitter being a notable exception.
- Terretta 11y ago
  You're a robot. What do you care?
vonklaus 11y ago
I still don't think this makes sense. You can just get a static IP and point it at a load balancer. How would this help if your site fails? You can cname undfecarriage services like api and blog. What do you gain from www?
hasenj 11y ago
Two reasons are listed: - DNS records - Cookies Both of these things seem to have been design with "www" in mind. So the reason boils down to: original specs of various technologies are optimized around the assumption that your site will have a www (or more accurately: a subdomain rather than a naked domain). I find "www" aesthetically unpleasant. If one must use a subdomain, how about "web" instead? It's still three characters, but much cleaner.
- brianwawok 11y ago
  "web" would also satisfy all of the requirements, at the expense of not following convention.
christianbryant 11y ago
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.
- robszumski 11y ago
  As mentioned on the site, there are some stipulations about cookies that are fairly important if you're doing something sophisticated.
mythz 11y ago
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: - stackoverflow.com - github.com - twitter.com - stripe.com
- erikb 11y ago
  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.
  - speakeron 11y ago
    They do redirect, but it's actually to go from the www to the naked domain. This always leaves the naked domain in the URL bar and is, to me, a clean look.
frogpelt 11y ago
www bothers me for mainly one reason. It is a pain to say. It is one of the few abbreviations that takes longer and more effort to say than the unabbreviated words themselves——world wide web.
- mgkimsal 11y ago
  And... few people actually pronounce it out. I've lost track over the years of hearing major media outlets give addresses as "double-you double-you double-you ourdomain dot com" Typing what they actually say will get you nothing, unless they were sharp enough to also get wwwourdomain.com
Scirra_Tom 11y ago
The "having to buy different domain names" to server static content seems like a really minor downside. Cookie point is a good point though.
braum 11y ago
brand awareness and recall is king for small niche companies. we removed the www to bring our brand, a unique but simple domain, into focus. IMHO if you have a trade and/or trademarked domain name and wish to get more organic traffic using a naked domain is the best choice.
alexshye 11y ago
Empirically, www seems to have won -- a large fraction of the top consumer sites online have picked it. One could make UI/UX-type arguments for no-www, but I sites like Facebook and Pinterest have some of the best UI/UX people in the world, and have still picked www. What is this the case? What is the top reasons for www? Is it the cookie thing? I've heard that www lets you play DNS trics also, but haven't seen more details on this. I'd love to hear more about this choice from people who understand the decisions at top Internet companies.
- darylteo 11y ago
  I'm a convert from non-www to www. Just avoids security implications re: cookies and no need to buy secondary domain for static assets. A simple redirect mitigates the "ux" argument that the domain looks less nice to type or read. Simple implementation with more pros than cons. Should add it's not a hard and fast rule, and depends on the use case. But the default question for me nowadays is "why no-www" and not "why www".
- the_mitsuhiko 11y ago
  A www. prefix just makes life easier for everybody from just running it so there is really not much reason for not having it. Supporting the redirect is easy and people generally don't seem to care.
cantrevealname 11y ago
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.")
- erikb 11y ago
  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.
- clinta 11y ago
  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 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.
spinningarrow 11y ago
> The technical reasons to use www primarily apply to the largest web sites which receive millions (or more) of page views per day 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'?
- bigjimmyk3 11y ago
  When you reach their size, it's not a big deal to build and maintain your own DNS serving infrastructure; in that case, you can do as you please, which might include serving up a pool of A records round-robin style or using an expensive magic DNS geodirector thingamabob.
- ef4 11y ago
  > Do they have to go through a lot of hoops in order to not use 'www'? No, they don't. The claim that apex domains can't be used with CDNs is badly out of date. Even a free-tier Cloudflare account supports CNAME flattening, which solves the problem just fine. https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root https://support.cloudflare.com/hc/en-us/articles/200169056-C...
dlsx 11y ago
I have an obsession with proper URL formatting, and I appreciate when my browser also takes this in to consideration. I always find the site loads quicker when I use www. and I will continue typing URLs in this way as I have become used to it for over a decade. The valid point this article makes is that there is not enough education or knowledge on this subject. Schools don't teach this, this is why there is cases of people typing URLs in to search engines. Computer classes apparently need to have a WEB 101 or something, because this lack of understanding of something so useful and basic is absurd.
chrisblackwell 11y ago
> 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.
- ymse 11y ago
  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.
  - developer2 11y ago
    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-for-amazon-s3/ https://aws.amazon.com/blogs/aws/root-domain-website-hosting...
    - treve 11y ago
      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.
  - elithrar 11y ago
    > 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-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root https://support.cloudflare.com/hc/en-us/articles/200169056-C...
Sidnicious 11y ago
I found this article hard to read. It seems to boil down to three points: 1. Some hosts might want you to use a CNAME record to send them your web traffic, and CNAME records are undesirable for apex domain names because they can't coexist with other records you might need (like MX). 2. Cookies set on the apex domain will be sent to subdomains. 3. Older browsers may not let the apex domain read cookies set by subdomains. Is that right? (CloudFlare deals with (1) by just hosting your DNS, and I don't have enough experience with (2) and (3) to have strong opinions on them.)
- deleted 11y ago
  [deleted]
- merbpoll 11y ago
  > 1. Some hosts might want you to use a CNAME record to send them your web traffic, and CNAME records are undesirable for apex domain names because they can't coexist with other records you might need (like MX). Nitpick: With the exception of RRSIGs, a CNAME record must be the only record at a given owner name. Since the apex of a zone has a SOA record, a CNAME cannot exist there.
dzuc 11y ago
some DNS services are providing "ANAME" http://www.dnsmadeeasy.com/services/anamerecords/ http://www.dnsmadeeasy.com/services/anamerecords/ for instance
- brandur 11y ago
  Exactly! It's a little questionable that the linked website doesn't mention the existence of these types of records considering how widespread they are these days. Every DNS host I've used in the last five years has supported something like "ANAME". For example: * CloudFlare's "CNAME Flattening": https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/ https://blog.cloudflare.com/introducing-cname-flattening-rfc... * DNSimple's ALIAS record: https://support.dnsimple.com/articles/alias-record/ https://support.dnsimple.com/articles/alias-record/ * Route 53's alias records: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/res... (although these need to go to an ELB, CloudFront distribution, S3 bucket, or Elastic Beanstalk environment)
  - merbpoll 11y ago
    Those are non-standard proprietary extensions that aren't universally available. Omitting them is not questionable.
Spooky23 11y ago
Missing reason: provides an anchor for weird domains. Imagine being confronted with something.nyc, or something.cool, or something.repair. WTF is it? That www gives you some context.
- djhn 11y ago
  Why not just http:// http://?
  - djsumdog 11y ago
    Exactly! http:// http:// makes a lot more sense, and people are less likely to track on a .com to the end
jacobsenscott 11y ago
Having run a website on an apex domain for over 5 years I can tell you all the mentioned issues are easy to overcome. But if you are a hobbiest or a novice at running a website (most startups) then this is good advice.
tamana 11y ago
I am glad to have some rando explaining how Google's domain names are wrong.
deathanatos 11y ago
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. (And you can weight records, assign priorities…) [1]: https://en.wikipedia.org/wiki/SRV_record https://en.wikipedia.org/wiki/SRV_record
- drdaeman 11y ago
  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.
- doublerebel 11y ago
  Consul service registry uses SRV records in this manner and it's fantastic. However, on the wider internet with third party services it's much easier to manage and debug dedicated port numbers.
zhte415 11y ago
Many many websites, fail to display anything if www is not prepended to the URL. Particularly of small businesses. If anyone if looking for a business development niche selling basic consulting to small and medium sized companies, it is this.
kmeisthax 11y ago
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.
tomphoolery 11y ago
"www." is just 4 more characters I have to put on the flyer. no-www til I die!!
jv22222 11y ago
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.
endemic 11y ago
What a bizarre advocacy site. If you need the subdomain, you'll use it. Otherwise, why make such an impassioned plea for 'www'?
pbhjpbhj 11y ago
Yes, but what about the trailing slash ...
downtide 11y ago
I've always hated the www prefix. But understand the technical gains of using one. If you are a domain owner, subdomains give you quite a bit of flexibility. You can always use a different prefix than www.
patsplat 11y ago
www is a relic of a different time, when networks were client-server first and http was an afterthought. Now it is expected that the root domain at minimum bring up a single page description of the org. Add the www cname with a redirect to the root, start phasing www out.
ludwigvan 11y ago
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."
jpswade 11y ago
Interesting that I responded to this in 2007 and it still rings true today! http://wade.be/yes-www/ http://wade.be/yes-www/ Somewhat ironically, in 2016 I've since moved to no www on my none business critical blog.
- theoh 11y ago
  Pedantic correction: that should be "non business-critical".
patsplat 11y ago
Don't get why blocking cookies to static.domain.com is a desired feature. Especially when sharing cookies btw app.domain.com and login.dimain.com would be desirable.
jpswade 11y ago
Interesting that I responded to this in 2007 and it still rings true today! http://wade.be/yes-www/ http://wade.be/yes-www/ Somewhat ironically, in 2016 I've since moved to no www on my none business critical blog.
arca_vorago 11y ago
With DNS and CAs as broken as they are, I'm skipping this and wondering not just go back to using IP addresses. (I am also the resident contrarian so...)
Rezo 11y ago
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 http://example.com redirects to https://example.com https://example.com, as does http://www.example.com 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 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 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 11y ago
  > And make sure the 3 redirects preserve any request URI parts after the domain as well. 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.
chrisweekly 11y ago
Use a CNAME. Here's another good explanation: https://www.netlify.com/blog/2016/01/12/ddos-attacks-and-dns-records https://www.netlify.com/blog/2016/01/12/ddos-attacks-and-dns...
excitom 11y ago
I dislike www simply because it is the world's worst acronym; having three times as many syllables as the words it replaces.
- njharman 11y ago
  dub dub dub ?
lkbm 11y ago
> 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) Am I just confused? [1] http://tools.ietf.org/html/rfc6265#section-4.1.2 http://tools.ietf.org/html/rfc6265#section-4.1.2
z3t4 11y ago
... Or you could just let your CDN control DNS. I think www is a relic from the days where you only had one host per server ... Or do you want to slap www infront of everything, like www.news.ycombinator.com !?

601 points by wfunction 11y ago

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?

vacri 11y ago
Regarding defunctness, there's nothing magical about the 'www' string - it can be anything, as long as it's not the DNS zone apex (~='base domain'). There are limitations on what you can do with the zone apex entry (such as no CNAMEing it), but no limitations on other entries. 'www' is just convention. As to your question, it's a bit of both. I'm not a network admin, though, so I'll let someone a bit more skilled pipe up. I have run into difficulties with migrating 'bare domains' in a small business environment due to these limitations, though. Not insurmountable, but required more work to cover the issues. Of course, when you're 'big', you'll be dealing with these kinds of issues a lot more.
yrro 11y ago
I can't for the life of me figure out why web browsers don't yet do a query for an SRV record named _http._tcp.example.com when the user browses to example.com.
- colanderman 11y ago
  There are old open bugs for this against most major browsers. See e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=14328 https://bugzilla.mozilla.org/show_bug.cgi?id=14328 For me, this would allow me to have domain names that point to various HTTP/HTTPS based services behind my single outward-facing IPv4 address. As-is, I have to memorize what non-standard ports they're on.
  - Sanddancer 11y ago
    Why not just use a reverse proxy and virtualhost entries? A straightforward proxy will take care of the hostnames, and SNI will handle https.
    - colanderman 11y ago
      The servers are located in different parts of the continent, and the only one that is capable of acting as a proxy has metered bandwidth, while one is interactive and another is a media server. I suppose I could set up a system of HTTP redirects but combined with HTTPS I feel that will get hairy quickly. The service-level redirection SRV records provide are really exactly match my needs.
- merbpoll 11y ago
  This came up again during http2. The browser vendors just aren't willing to take on the extra latency at the start of the request.
  - deleted 11y ago
    [deleted]
  - zrm 11y ago
    Where is the extra latency? You can do DNS queries for example.com and _http._tcp.example.com concurrently so that you get both answers in the time of one round trip to the DNS server. If there actually is a SRV record and the target isn't locally cached then you would need to do another query, but that is faster than establishing an HTTP session with example.com, getting the 301 redirect and then having to do the query anyway.
    - merbpoll 11y ago
      They didn't want to wait for multiple queries to finish. If you're interested in a detailed rationale you can take a look through the mailing list archives (though it'll be frustrating reading).
      - spc476 11y ago
        And that's because the major DNS servers don't bother with answering more than one question per query. Nothing in the DNS specification limits the number of questions to one. The only down side might be that the response to multiple questions might not fit in the standard UDP DNS packet.
        merbpoll 11y ago
        DNS servers can't answer more than one question per query because NXDOMAIN is signalled in the message header and so when QDCOUNT is greater than one the response becomes ambiguous.

nailer 11y ago

Previously: https://news.ycombinator.com/item?id=7961415 https://news.ycombinator.com/item?id=7961415

tantalor 11y ago

See also these directions for redirecting naked domain to www, http://www.yes-www.org/redirection/ 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 11y ago
wwwizer - http://wwwizer.com/naked-domain-redirect http://wwwizer.com/naked-domain-redirect
deckar01 11y ago
I guess they don't provide DNS ALIAS records. I normally see subdomain redirects implemented as an HTTP 301 redirect in the server configuration.

r3bl 11y ago

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.

akcreek 11y ago
301 redirect the naked domain to the www and you can keep telling people the same thing - they will be redirected to the www version seamlessly.
- clessg 11y ago
  You can do that, but the redirect will affect initial load times. Might be worth it, might not be.
mbrock 11y ago
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...
lowmagnet 11y ago
I used to host at lowmag.net (my old username, still used in places like hn for laziness puposes) I now use the bare version of my name plus .com.

Palomides 11y ago

you don't need to do a mod_rewrite thing, btw, just do: <VirtualHost *:80> ServerName whatever.com Redirect permanent / http://www.whatever.com/ </VirtualHost>

envy2 11y ago
Honestly, if you're running on a simple Apache config, you almost certainly don't need to worry about any of the technical issues the article raises.
- hueving 11y ago
  If your service requires scaling because it's expensive dynamic content, then apache could easily be fast enough and not the bottleneck requiring a switch to something else. It doesn't matter if nginx/whatever can handle 1000+ reqs/sec if your app consumes 300MB of ram per request and takes 1 second to process.
perlgeek 11y ago
That either doesn't redirect "deep" links, or it redirects them to the start page.
- walod 11y ago
  Got any proof of a case where this happens? I'm using it to redirect to https:// https:// and it redirects deep links to the right deep links, and nothing goes to the home page
- Palomides 11y ago
  I'm running it on my personal site and all links work as intended

CrowFly 11y ago

And, while we're on this topic, news.x.x should be for services using the NNTP.

feelix 11y ago

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.

deleted 11y ago
[deleted]
jlg23 11y ago
> 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."
- id 11y ago
  What is your point? I mean, everything the parent wrote still applies.
  - Klinky 11y ago
    For very little effort you can simply redirect your main domain, and gain the technical benefits/simplicity of having a www subdomain, all while not inconveniencing your users. This pretty much makes the parent's point of hosting actual content on the main domain for customer convenience moot.
  - deleted 11y ago
    [deleted]

mattiemass 11y ago

Welp, stupidly I dropped the www with zero research because I saw others do it. Love the explanation of why keeping the www is useful.

brianwawok 11y ago
I did too. Then I wanted to host a webpage out of google cloud drive. Opps, doesn't support naked domains. Back to www in the future.

bobfunk 11y ago

We also strongly discourage users from using naked domains, unless they have a DNS host that supports ALIAS records or CNAME flattening. 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-records https://www.netlify.com/blog/2016/01/12/ddos-attacks-and-dns...

tamana 11y ago
Your post is grey, light-weight text, which is two reason people won't read it.
- megablast 11y ago
  And the background isn't even white. Come on!
  - switch007 11y ago
    And "font-weight: 300", naturally. Argh!

marcosdumay 11y ago

Well, the obligatory counterpart: http://no-www.org/ http://no-www.org/

EugeneOZ 11y ago
"Technical part" is not as convincing. P.S., About cookies: Don't use cookies, LocalStorage is much better.
- michaelmior 11y ago
  > Don't use cookies, LocalStorage is much better. Source? Not saying I agree or disagree, but a statement like that without any supporting arguments or discussion isn't particularly helpful.
  - EugeneOZ 11y ago
    Have you tried to find something? Let me help you: http://caniuse.com/#feat=namevalue-storage http://caniuse.com/#feat=namevalue-storage http://stackoverflow.com/a/3220802/680786 http://stackoverflow.com/a/3220802/680786 In short: LocalStorage is supported by all browsers, has no security issues as cookies have, has much bigger storage limit, much more handy API and don't need to be send on each request.
- tiglionabbit 11y ago
  It doesn't accomplish the same thing. Cookies are added to every web request, while you have to supply your localstorage values manually if you want to use them. At the least, this requires JavaScript. It's also impossible to do for regular clicks on links and when loading images and scripts. Sometimes you want to authenticate those too.
  - EugeneOZ 11y ago
    Ok, I'll rephrase: only use cookies when you want to send them with requests to static files. But don't forget - you will not be able to use CDN in this case.

Smudge 11y ago

yes-www is clearly the more practical solution based on current technology and its limitations. And no-www (http://no-www.org/ http://no-www.org/) is clearly the more aesthetic solution. Either is perfectly valid, and depending on who you ask you'll get reasonable arguments in favor of both. That said, neither choice will ultimately make any difference. Period. Even if your site becomes the next Google, the minor hurdles of a no-www domain vs the technical advantages of a yes-www domain will not make an ounce of difference. Anyone who tells you otherwise is straight up fooling themselves.

hartator 11y ago

Your users won't save 4 chars...

robot 11y ago

whichever the reasons, I should take the toll by typing www every time? life is too short.

mastazi 11y ago
No you shouldn't, the article suggests server-side redirection so you don't have to type www in front of the url. Many of the highest-traffic websites already do that, Twitter being a notable exception.
Terretta 11y ago
You're a robot. What do you care?

vonklaus 11y ago

I still don't think this makes sense. You can just get a static IP and point it at a load balancer. How would this help if your site fails? You can cname undfecarriage services like api and blog. What do you gain from www?

hasenj 11y ago

Two reasons are listed: - DNS records - Cookies Both of these things seem to have been design with "www" in mind. So the reason boils down to: original specs of various technologies are optimized around the assumption that your site will have a www (or more accurately: a subdomain rather than a naked domain). I find "www" aesthetically unpleasant. If one must use a subdomain, how about "web" instead? It's still three characters, but much cleaner.

brianwawok 11y ago
"web" would also satisfy all of the requirements, at the expense of not following convention.

christianbryant 11y ago

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.

robszumski 11y ago
As mentioned on the site, there are some stipulations about cookies that are fairly important if you're doing something sophisticated.

mythz 11y ago

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: - stackoverflow.com - github.com - twitter.com - stripe.com

erikb 11y ago
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.
- speakeron 11y ago
  They do redirect, but it's actually to go from the www to the naked domain. This always leaves the naked domain in the URL bar and is, to me, a clean look.

frogpelt 11y ago

www bothers me for mainly one reason. It is a pain to say. It is one of the few abbreviations that takes longer and more effort to say than the unabbreviated words themselves——world wide web.

mgkimsal 11y ago
And... few people actually pronounce it out. I've lost track over the years of hearing major media outlets give addresses as "double-you double-you double-you ourdomain dot com" Typing what they actually say will get you nothing, unless they were sharp enough to also get wwwourdomain.com

Scirra_Tom 11y ago

The "having to buy different domain names" to server static content seems like a really minor downside. Cookie point is a good point though.

braum 11y ago

brand awareness and recall is king for small niche companies. we removed the www to bring our brand, a unique but simple domain, into focus. IMHO if you have a trade and/or trademarked domain name and wish to get more organic traffic using a naked domain is the best choice.

alexshye 11y ago

Empirically, www seems to have won -- a large fraction of the top consumer sites online have picked it. One could make UI/UX-type arguments for no-www, but I sites like Facebook and Pinterest have some of the best UI/UX people in the world, and have still picked www. What is this the case? What is the top reasons for www? Is it the cookie thing? I've heard that www lets you play DNS trics also, but haven't seen more details on this. I'd love to hear more about this choice from people who understand the decisions at top Internet companies.

darylteo 11y ago
I'm a convert from non-www to www. Just avoids security implications re: cookies and no need to buy secondary domain for static assets. A simple redirect mitigates the "ux" argument that the domain looks less nice to type or read. Simple implementation with more pros than cons. Should add it's not a hard and fast rule, and depends on the use case. But the default question for me nowadays is "why no-www" and not "why www".
the_mitsuhiko 11y ago
A www. prefix just makes life easier for everybody from just running it so there is really not much reason for not having it. Supporting the redirect is easy and people generally don't seem to care.

cantrevealname 11y ago

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

erikb 11y ago
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.
clinta 11y ago
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 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.

spinningarrow 11y ago

> The technical reasons to use www primarily apply to the largest web sites which receive millions (or more) of page views per day 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'?

bigjimmyk3 11y ago
When you reach their size, it's not a big deal to build and maintain your own DNS serving infrastructure; in that case, you can do as you please, which might include serving up a pool of A records round-robin style or using an expensive magic DNS geodirector thingamabob.
ef4 11y ago
> Do they have to go through a lot of hoops in order to not use 'www'? No, they don't. The claim that apex domains can't be used with CDNs is badly out of date. Even a free-tier Cloudflare account supports CNAME flattening, which solves the problem just fine. https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root https://support.cloudflare.com/hc/en-us/articles/200169056-C...

dlsx 11y ago

I have an obsession with proper URL formatting, and I appreciate when my browser also takes this in to consideration. I always find the site loads quicker when I use www. and I will continue typing URLs in this way as I have become used to it for over a decade. The valid point this article makes is that there is not enough education or knowledge on this subject. Schools don't teach this, this is why there is cases of people typing URLs in to search engines. Computer classes apparently need to have a WEB 101 or something, because this lack of understanding of something so useful and basic is absurd.

chrisblackwell 11y ago

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

ymse 11y ago
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.
- developer2 11y ago
  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-for-amazon-s3/ https://aws.amazon.com/blogs/aws/root-domain-website-hosting...
  - treve 11y ago
    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.
- elithrar 11y ago
  > 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-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root https://support.cloudflare.com/hc/en-us/articles/200169056-C...

Sidnicious 11y ago

I found this article hard to read. It seems to boil down to three points: 1. Some hosts might want you to use a CNAME record to send them your web traffic, and CNAME records are undesirable for apex domain names because they can't coexist with other records you might need (like MX). 2. Cookies set on the apex domain will be sent to subdomains. 3. Older browsers may not let the apex domain read cookies set by subdomains. Is that right? (CloudFlare deals with (1) by just hosting your DNS, and I don't have enough experience with (2) and (3) to have strong opinions on them.)

deleted 11y ago
[deleted]
merbpoll 11y ago
> 1. Some hosts might want you to use a CNAME record to send them your web traffic, and CNAME records are undesirable for apex domain names because they can't coexist with other records you might need (like MX). Nitpick: With the exception of RRSIGs, a CNAME record must be the only record at a given owner name. Since the apex of a zone has a SOA record, a CNAME cannot exist there.

dzuc 11y ago

some DNS services are providing "ANAME" http://www.dnsmadeeasy.com/services/anamerecords/ http://www.dnsmadeeasy.com/services/anamerecords/ for instance

brandur 11y ago
Exactly! It's a little questionable that the linked website doesn't mention the existence of these types of records considering how widespread they are these days. Every DNS host I've used in the last five years has supported something like "ANAME". For example: * CloudFlare's "CNAME Flattening": https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/ https://blog.cloudflare.com/introducing-cname-flattening-rfc... * DNSimple's ALIAS record: https://support.dnsimple.com/articles/alias-record/ https://support.dnsimple.com/articles/alias-record/ * Route 53's alias records: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/res... (although these need to go to an ELB, CloudFront distribution, S3 bucket, or Elastic Beanstalk environment)
- merbpoll 11y ago
  Those are non-standard proprietary extensions that aren't universally available. Omitting them is not questionable.

Spooky23 11y ago

Missing reason: provides an anchor for weird domains. Imagine being confronted with something.nyc, or something.cool, or something.repair. WTF is it? That www gives you some context.

djhn 11y ago
Why not just http:// http://?
- djsumdog 11y ago
  Exactly! http:// http:// makes a lot more sense, and people are less likely to track on a .com to the end

jacobsenscott 11y ago

Having run a website on an apex domain for over 5 years I can tell you all the mentioned issues are easy to overcome. But if you are a hobbiest or a novice at running a website (most startups) then this is good advice.

tamana 11y ago

I am glad to have some rando explaining how Google's domain names are wrong.

deathanatos 11y ago

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. (And you can weight records, assign priorities…) [1]: https://en.wikipedia.org/wiki/SRV_record https://en.wikipedia.org/wiki/SRV_record

drdaeman 11y ago
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.
doublerebel 11y ago
Consul service registry uses SRV records in this manner and it's fantastic. However, on the wider internet with third party services it's much easier to manage and debug dedicated port numbers.

zhte415 11y ago

Many many websites, fail to display anything if www is not prepended to the URL. Particularly of small businesses. If anyone if looking for a business development niche selling basic consulting to small and medium sized companies, it is this.

kmeisthax 11y ago

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.

tomphoolery 11y ago

"www." is just 4 more characters I have to put on the flyer. no-www til I die!!

jv22222 11y ago

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.

endemic 11y ago

What a bizarre advocacy site. If you need the subdomain, you'll use it. Otherwise, why make such an impassioned plea for 'www'?

pbhjpbhj 11y ago

Yes, but what about the trailing slash ...

downtide 11y ago

I've always hated the www prefix. But understand the technical gains of using one. If you are a domain owner, subdomains give you quite a bit of flexibility. You can always use a different prefix than www.

patsplat 11y ago

www is a relic of a different time, when networks were client-server first and http was an afterthought. Now it is expected that the root domain at minimum bring up a single page description of the org. Add the www cname with a redirect to the root, start phasing www out.

ludwigvan 11y ago

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

jpswade 11y ago

Interesting that I responded to this in 2007 and it still rings true today! http://wade.be/yes-www/ http://wade.be/yes-www/ Somewhat ironically, in 2016 I've since moved to no www on my none business critical blog.

theoh 11y ago
Pedantic correction: that should be "non business-critical".

patsplat 11y ago

Don't get why blocking cookies to static.domain.com is a desired feature. Especially when sharing cookies btw app.domain.com and login.dimain.com would be desirable.

jpswade 11y ago

arca_vorago 11y ago

With DNS and CAs as broken as they are, I'm skipping this and wondering not just go back to using IP addresses. (I am also the resident contrarian so...)

Rezo 11y ago

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 http://example.com redirects to https://example.com https://example.com, as does http://www.example.com 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 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 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 11y ago
> And make sure the 3 redirects preserve any request URI parts after the domain as well. 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.

chrisweekly 11y ago

Use a CNAME. Here's another good explanation: https://www.netlify.com/blog/2016/01/12/ddos-attacks-and-dns-records https://www.netlify.com/blog/2016/01/12/ddos-attacks-and-dns...

excitom 11y ago

I dislike www simply because it is the world's worst acronym; having three times as many syllables as the words it replaces.

njharman 11y ago
dub dub dub ?

lkbm 11y ago

> 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) Am I just confused? [1] http://tools.ietf.org/html/rfc6265#section-4.1.2 http://tools.ietf.org/html/rfc6265#section-4.1.2

z3t4 11y ago

... Or you could just let your CDN control DNS. I think www is a relic from the days where you only had one host per server ... Or do you want to slap www infront of everything, like www.news.ycombinator.com !?