Why use www?
yes-www.org
yes-www.org
The CNAME argument is obsolete since most DNS providers support ALIAS records now.
The static no-cookie argument doesn't really matter since you could always serve static content on a separate domain altogether (ex: fbcdn.net).
However, if you want to run hosted services on subdomains, you run into an important security issue. For example, say you have Zendesk hosted on support.mysite.com. You don't want to leak session cookies from mysite.com to support.mysite.com. In most browsers, you can just specify the cookie domain and it will only be sent to the root domain. However, NO versions of IE respect this (even IE 10+) [1]. So your IE users will always leak session cookies to hosted services on subdomains. In any reasonably secure site, this is unacceptable (especially when you start using other hosted services for status.mysite.com, careers.mysite.com, etc etc).
Unfortunately, this is pretty much impossible to work around, unless you want to ban IE users from using your site entirely.
Solution: Just use www (or any other subdomain, if you want to be different) from the start, and save yourself the headache of migrating later.
[1] http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/winin...
I mean, would you recommend to set cookies with domain mysite.com and thus have a different domain for external services, like support.mysite.net, or...? (genuinely asking, I don't mean to criticize, sorry if the english is not perfect :)
www.mysite.com
support.mysite.com
wordpress.mysite.com
You could use *.secure.mysite.com for all internal apps, but that seems ugly. You could also not use subdomains for any internal apps, like Google, but that's limiting in other ways - notably, it makes it impossible to have any security isolation between internal apps.
Issue a master session cookie at login.mydomain or account.mydomain. If your user hits a subdomain and is not logged in, forward them there (in the background) and see if you can grant them a redeemable token for the round trip. If so, they can get a cookie issued by the subdomain in exchange for the token when they return.
I guess there is still some tricks when the user lands in a subdomain and needs to be redirected to another, e.g. www -> mobile, but I'll figure out the details :)
The really big argument for me was: laypeople just expect the "www". Losing it means having to repeat and explain things. It's just not worth it.
The technical "solution" is only half the story. You break people's expectations, you get questions.
[1] http://raamdev.com/2010/php-session-permission-denied-errors...
2. The solution provided does not solve the problem of foo.com not trusting bar.foo.com.
2. The post was written in an exploratory tone, not a factual, "here are the facts, here's how to solve this problem across all scenarios" tone.
Thanks for your feedback.
DNSMadeEasy has ANAME for somewhat similar purpose [2].
It's worth noting that AWS CloudFront works ONLY with AWS Route 53 for the proper latency-based routing with root domains. Yes, DNSMadeEasy ANAME works with CloudFront too but it's not smart about returning the closest edge to the user.
[1] http://aws.amazon.com/about-aws/whats-new/2013/06/11/announc...
[2] http://www.dnsmadeeasy.com/press-release/dns-made-easy-intro...
But performance-wise if the cookie is just a session id then maybe sending a few hundred bytes extra with each resource request doesn't even show up in profiling.
With cookies the number of connections opened remains the same, amount of bytes received remains the same.
Most of the network time with a pageload is wasted on opening a connection for each resource and streaming the output, if there's a need to optimize then instead of getting rid of cookies it's better to concat resources etc or move to SPDY.
OR, just buy that second domain for static content if client-side performance becomes that important and sending unneeded cookies feels like a waste :)
And if you get a client that isn't using ethernet (maybe GSM, what is its minimum package size?), they'll probably use large TCP packets too, and pad at that level.
If there's anything that will make me reluctantly enforce a www subdomain, it would be security.
Enabling do not track adds about as much header info as a php session cookie, should we be advising people not to enable do not track as it will affect performance? That's just silly.
I mean either way were adding only a few bytes to the request.
If the issue is caching based on headers that is an awful naive CDN as there are going to be literally thousands of variations in the user agent and accept language headers.
I mean maybe a few bytes for headers made a difference in dial up days but I assure you they make no difference today.
I would argue, IMO, when you need to expand you subdomains in the future, mixing naked domain and subdomains is even more uglier, and cause the inconsistencies, e.g.
example.com api.example.com admin.example.com
When we are talking about the default, it should be safe to use, and "www" is the safe choice here for people who NEVER heard about the CNAME and the cookie issues. Advertising something (like http://no-www.org) for the matter of taste without mentioning the potential drawbacks (even there are workarounds), is irresponsible IMO.
That seems perfectly normal to me. The first one is the main service, the second is the API for that service, the third the admin site for that service.
Whether you use www or not wont it will still be two DNS requests?
www.mysite.com
static.mysite.com mysite.com
mysitestatic.comAnd it does it through an hardcoded alias and not a cname. How clever.
By default, all popular Web browsers assume the HTTP protocol. In doing so, the software prepends the 'http://' onto the requested URL and automatically connect to the HTTP server on port 80. Why then do many servers require their websites to communicate through the www subdomain? Mail servers do not require you to send emails to recipient@mail.domain.com. Likewise, web servers should allow access to their pages though the main domain unless a particular subdomain is required.
You mean host. www is a host in example.com. Protocol indicator (http/https) and host name (www, mail, bob) have nothing to do with each other.
You don't have to do @host.example.com if there is a special DNS record for SMTP to indicate where to actually send mail, without it you do have to do host.example.com.
> automatically connect to the HTTP server on port 80
What HTTP server? if the URL is www.example.com we connect to the server named www, it could be named bob if we wanted. Without the host name given you have to create a catchall to tell clients to send ALL traffic without a hostname to.
The comparison between protocols is really stupid.
Even their FAQ doesn't answer why they dislike 'www' other than being seemingly redundant. I personally prefer without www on my websites, and my cache server is set up to ignore cookies on static content.
"However, any site that takes in traffic one way or the other on both the www host and the bare domain are acceptable here."
Well, if you get a huge site, and are still using those providers, or can't spare an extra $20 yearly, well, you have some much larger problem than the lack of "www" prefix.
Also, having an ugly URL just because one day you may become big and need it is a fool's errand. Use the pretty one, and when that day comes, change it. It's a one line change in the server settings, and there is no penalty on links, search ranking, or anything else.
[1] Ignore that in most cases those cookies don't consume any extra bandwidth. Network communication is normally padded to multiples of some relatively big size, and requests for static data is quite small. If you use very large cookies, then yes, maybe you should think about spending those $20, or adding the "www" once your site grows.
Citation needed.
(my co-workers understand this, and I think it's growing on a few. One still resists.)
"Go to foobar.com"
"It's not working"
"Try with dub dub dub"
As an aside, it's so painful to listen to radio commercials from advertising agencies that thought it was a good idea to include "www" in the script. "Just go to double-yew double-yew double-yew..."
We don't have a "w" in our alphabet, and a name for it though.. That might be the reason.
We do say BMV though. And I've heard may people saying "v", but most? I'm now sure. I could be living in a bubble.
Don't be dense. I wasn't suggesting anything of the sort.
The point of my comment was one of humor (apparently that's verboten?), and therefore the intent was that a Danish person who also knows English may have something of a chuckle when they see abbreviations of it in English as a direct result of the OP's comment.
Further, since I assume "VC" comes from the Danish word(s) for "water closet," it's fairly reasonable to believe that a faint glint of humor crosses the mind of Danish people when they read such English abbreviations assuming they know English.
Humor loses its value when it must be explained.
I'm quite an amenable person and would like to know precisely what it is I'm doing wrong here.
I do appreciate the subtle tongue-in-cheek reference, though (I chuckled). +1.
That depends on your handwriting and/or typeface.
nope, sorry. i have no desire for my sites to be big. i prefer rememberable to a few, over big. next. can someone tell me why these people are actually pushing www use? So far the reasons they state make no sense. It sound's like a bunch of grammar addicts getting into the technologist scene.
> Twitter, for instance, which does not use www, had to buy new domain names just for static content.
and, who cares? If you become a really "big" website I guess you can afford another domain name.
> You may not run into any of these issues today, but as your web site grows, you eventually will.
What I learned from this. When my site get's so big that I can sniff coke off of male escorts I should hire someone to deal with purchasing more domains for our cookie content issue. thanks, solved.
Don't tell these little sites: stackoverflow.com, rapgenius.com, foursquare.com, twitter.com, instagram.com, ask.fm, wordpress.com, imgur.com, vimeo.com, hootsuite.com, github.com
It seems like people are just looking for ways to rationalize their preference for seeing "www" in URLs, so are latching onto any and every possible argument to justify that bias.
There are a few valid considerations on both sides, but ultimately this strikes me as just the latest bit of churn in tech fashion.
So, www is your web service.
If you'd like a proposal, add a new type of DNS record, like the MX record, specifically for HTTP.
Getting adoption at the client end is likely the limiting factor.
This bug/request has been sitting since last century.
It makes life easier if I know I can access my web servers at www.whatever.com and my FTP servers at ftp.whatever.com, rather than trying to remember that morpheus.whatever.com runs web services because it has port 80 open, or needing to worry about the FTP server also running an HTTP server on port 80 for its stats dashboard, etc.
Yes, if all you have is one IP.
Now back in the real world, we aren't trying to create new problems to solve where we already have solutions.
web.example.com
The way it should have been since day one.
$ curl -I mit.edu
HTTP/1.1 302 Moved Temporarily
Server: AkamaiGHost
Content-Length: 0
Location: http://web.mit.edu/
Date: Mon, 30 Jun 2014 03:12:18 GMT
Connection: keep-alive
Obviously www. is extraneous if you can get the CNAME functionality.
The CNAME Flattening feature is awesome, and according to David Ensinger (http://davidensinger.com/2014/04/transferring-the-dns-from-n...) there are a bunch of neat performance boosts too.
My site: http://derick.is/
"W" is a letter that is not one syllable, for that would be too few, a letter that is not two syllables, for that too would be too few, but a letter, in fact the one letter of all twenty-six that insists upon blathering on and on in its attempt to twist the tongue and overtax the ear, extending to the full three, yes three--three syllables, the legal alphabetical maximum. But wait, my friend. That is only the beginning. We go on to treble the damages by repeating this freak letter, this monstrosity that is one thing, claims to be two other things, but is really three things, not once, not twice, but a full three times, in a nonometric rhapsody fleshed out to the nines, a compound triplicate triumphant cat-o'-nine-tails tongue-lashing, a nonotuple witches' syllabic brew of treble, treble, toil and trouble. It is enough I say! Nine times enough, in fact. :-)
Them's the breaks one is dealt by one's language of choice. (I'm English, but in Switzerland, and have clearly noticed the ease of the alternative... ;) )
Isn't this pre-optimizing? You can use naked domains today and redirect tomorrow when it becomes an issue (IF it's still a technical issue we need to worry about at that time).
301 is built for this.
Or, when you do become big, this becomes a tiny issues.
> Twitter, for instance, which does not use www, had to buy new domain names just for static content.
Do you think Twitter struggled to afford this in any way?
> You may not run into any of these issues today, but as your web site grows, you eventually will.
Again, a big company can easily afford this. Do things that don't scale. Worrying about www should not be your initial concern.
Regarding "who cares about urls nowadays?", clearly the people in this thread making passionate arguments for and against a leading www. care :)
example.com/home?a=foo&b=bar
www.example.com/home?a=foo&b=bar
And thus we return to my original question: Is there a way to do forwarding at the registrar level in a way that preserves the rest of the URL structure?
If you're willing to work at a less general level than the registrar, a Ruby gem called Refraction used to work for forwarding in Rails projects (I used it for the Ruby on Rails Tutorial and The Tau Manifesto), but Refraction rules included in a recent Rails project (the most recent iteration of http://tauday.com/) were seemingly ignored. Some Googling revealed a couple of possible more up-to-date solutions:
https://github.com/cwninja/rack-force_domain
https://github.com/tylerhunt/rack-canonical-host
I have yet to try them out, but they look promising.
As an aside, when someone asks a question of the form "How do I do X without feature Y?", it's rarely helpful to respond with something like "Why not use Y?" Typically, the person asking the question has a reason for not using Y, and by making not using Y part of the question they're trying to avoid exactly the kind of digression that happened in this thread.
EDIT (because HN won't let me reply): I agree that it's sometimes worth understanding why they want to do X without Y, but it's best done with a lightness of touch. Otherwise you risk not giving the asker the benefit of the doubt (e.g., via statements like "So? Your redirects don't need to be at Heroku."). It's usually better to either answer the original question as stated or tread very carefully, with phrasing like "I'd like to understand your reasons for not wanting to use Y" rather than the blunter "What's wrong with Y?"
UPDATE: I can confirm that [rack-canonical-host](https://github.com/tylerhunt/rack-canonical-host) does the kind of forwarding I wanted, as you can verify by visiting, e.g., http://tauday.com/tau-manifesto?foo=bar, which is correctly forwarded to http://www.tauday.com/tau-manifesto?foo=bar.
Depends on your registrar.
> As an aside, when someone asks a question of the form "How do I do X without feature Y?", it's rarely helpful to respond with something like "Why not use Y?" Typically, the person asking the question has a reason for not using Y, and by making not using Y part of the question they're trying to avoid exactly the kind of digression that happened in this thread.
Sure, but it is sometimes worth asking why someone wants to know how to do X without Y.
This works pretty well and sets up quickly; it uses AWS Route 53 to provide 301 redirects automatically.
For e.g http://ABC.com/my-seo-url vs http://www.xyz.com/my-seo-url
www.wikipedia.org is not suffering from the www
The only potential implication, is if users prefer your domain with a www or without for some reason, and that that causes a higher engagement level, more clicks in google search results, more social sharing, and so on. That would be considered an indirect SEO impact (and would likely vary widely from site to site and demographic to demographic), as Google does not rank either positively or negatively just for the www.
I recall the first time hearing it in German - simply 'vay vay vay' - much easier!
dub dub dub dot siteurlhere dot com
it may not be correct but its understandable in context
Hosting anything serious on Heroku seems like craziness to me, but perhaps some people have identified uniquely good reasons to do it...
You just shouldn't. It's a relic of the times when protocol was embedded in the URL to differentiate ftp from http or gopher.
As an outsider (non-web software developer), I have to say debates like these hint strongly (IMO) of a cargo cult technology culture surrounding web development. Of course I get that we have to work with existing infrastructure; however I must admit it's surprising so many people seem blind to the idea that maybe the issue shouldn't exist in the first place.