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.
that's great, mail servers have an MX record, rather than relying on an A record for the base domain to provide only one service, which can cause confusion with other services.
> Why then do many servers require their websites to communicate through the www subdomain?
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.
That's absolutely not how it works. Firstly, "www" is a subdomain of "example.com". The subdomain could match the hostname of the server that hosts it, but that's rarely the case (there can be multiple servers behind a load-balancer, for example). Secondly, you don't have to create a wildcard record for "example.com" to work. You just have to add an A record for it (just like you would do for any subdomain thereof).
And if any web browser supported SRV records to do this properly, we wouldn't have an issue. You don't have to use mail.domain.com because MX records were created to solve this exact issue for mail servers. SRV records were a general purpose solution to the same problem.
Their argument seems only to be that with the https?:// protocol prefix in the URI, the 'www' is redundant. No other arguments than 'time consuming' is presented.
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.
OK, but that doesn't address any of the issues presented in the Yes WWW article posted here. I don't even see an argument against WWW other than convenience or aesthetics.
The issues in that article are basically that "such provider can't support the usual DNS configuration", and that "you'll either send cookies[1] to get static data, or will have to spend $20 more every year", and that both of those will become a problem when your site gets huge.
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.
Performance penalty is no longer an issue with AWS: CloudFront support for root domain/zone apex has been there since June 2013 [1].
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.
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 :)
Odds are your client will send those cookies by some ethernet network, that'll pad every package into a minimum size much larger than the request anyway.
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.
Large websites maintained by many teams tend to accumulate cookies over time. When you have dozens of cookies for various one-off purposes, getting rid of a cookie means tracking down all the places where it might be used. It's easier if it's set on a subdomain.
That's a ridiculously specific use case, and unless you're making a web host service, you're not really going to be running into that security issue. It's good to think about, but unlikely to happen.
It's not that specific. I know lots of companies will use a third party service for something like a helpdesk and will setup support.theirdomain.com to point to the third party. The cookies for the root may then be leaked to the third party.
How many cookies do you have that it affects performance?
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.
Well, if we're talking about "millions (or more) of page views per day", as the article is, the cost of buying an extra domain for static content is insignificant. You could also serve your static content from your CDN provider's domain.
Yes you are right, there are always workarounds! But why not make your life easier by just accepting...the "www" as the default? It is a convention well understood by most people in the Interweb. Honestly, I cannot see any technical reason to support removing "www" except someone's personal preferences.
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.
www. used to be convention, but it doesn't seem to be anymore. Listening to the way people talk casually, they'll say "go to [site].com, not [prefix].[site].com". www. seemed to be the standard back when people were confused about how slashes worked or what bit goes where. Now it's just [site], with a .com on the end to indicate it's a website (sometimes even if it's not a .com...)
No reason is given why you should use www. The only arguments presented here are a couple technical issues with having naked domains. But you could have w.example.com or foo.example.com and address those same problems.
you should use www because it is the convention, and no meaning is assigned to it. if you use w.example.com people will assume the w has some meaning, or try to read your domain as "wexample"
If that's the only valid reason to use "www" (as opposed to "mmm" or anything else) then why wouldn't an article titled "Why use www?" mention it?
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.
Do we? The most common time-saving pronunciation I have heard simply uses the initial 'w' sounds from the three words, and therefore has three syllables.
I just looked at the Wikipedia page for http://en.wikipedia.org/wiki/Pronunciation_of_%22www%22 and have never seen so much unsourced drivel in my life. For the record, I have been pronouncing it the way I described in the GP comment for the last twenty plus years, so that's some sort of data point.
Around my workplace we say "dub dub dub", or I do, at least. I think originally I picked it up from a Matt Cutts video on the Google Webmaster Central YouTube channel.
From the US, and I also use "dub dub dub" (picked it up from my networking professor…), I've also used "hup-ta" to refer to "http://". ("hup-tis" is https://) It sounds ridiculous, but it flows a lot better than "ache tee tee pee colon slash slash".
(my co-workers understand this, and I think it's growing on a few. One still resists.)
We use "dub dub dub" at work, though typically not when speaking the full name of the url. That may sound weird, so here's an example exchange:
"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..."
That's not really a problem, since in Denmark people speak Danish and "venture capital" is not a Danish word, so people aren't saying it, nor writing abbreviations of it intermixed with other Danish language.
> That's not really a problem, since in Denmark people speak Danish and "venture capital" is not a Danish word, so people aren't saying it, nor writing abbreviations of it intermixed with other Danish language.
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.
I haven't done any voting myself (but thanks for naturally assuming), but if I would venture a guess, it would be that your reply was considered off topic and that it added nothing to the discussion.
Fair enough, and I apologize for making such an outrageous assumption. In fairness, I think I may have misread the tone of your original post and was a little miffed. (Not appropriate, but we all make mistakes--mine are just more regular than they ought to be.)
I do appreciate the subtle tongue-in-cheek reference, though (I chuckled). +1.
When saying your domain name aloud, you never have to say www if your naked domain automatically redirects to your www. subdomain. Most of the time when people say it, it's completely unnecessary. I suppose you could use another subdomain to fulfill the same purpose of 'www' but 'www' is such a common convention that you would then probably need to redirect your users from www to whatever other subdomain you use.
You use www for the same reason that the ftp server is ftp.X and the mail server is mail.X. This allows organisations to have logical service locations separate from their current configured location.
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.
It looks like one of those bugs requesting a new feature that sits there for years until Chrome implements the same feature (in a Google-specific partial way). Only then Mozilla rushes to implement it, but at that point it is too late and Google takes all the merit for leading the web forward.
Well, it wouldn't be too hard to imagine a scenario where someone needs to SSH into the company WWW server on port 22, which is of course a different machine than the FTP server that they also sometimes need to SSH into on port 22, etc... Naming groups of machines under a subdomain that describes the function they perform is an easy way to reconcile the fact that we sometimes have multiple instances of the same service running on different machines in our network (and need to access them individually).
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.
Since the original TBL web server was at 'info.cern.ch' I think everyone has been Doing It Wrong since then, and we should replace 'www' with 'info' everywhere. I'm off to create 'info.not-www.org', I think...
This is a nice piece about engineering. However, it would be nice to see an A/B test for what the users prefer. The technical drawbacks don't seem large compared to, say, +1% better conversion rate for people seeing your URL in media and typing it into a browser.
I used to be strongly in the no-www camp for aesthetic reasons, but have since come around. There are legitimate reasons why having www (or any subdomain) is important in any large site.
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.
What about internal services with subdomains? What if, for instance, you have myservice.mysite.com and you want to share cookies among www and myservice?
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 :)
Then it's impossible to give only certain ones access to your session cookie.
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.
Downvoters — Please explain why this is a bad post. As someone in the process of learning how to run web services, explicit discussion of benefits and costs is very helpful.
Use oauth tokens or a similar mechanism to clone session tokens between (sub)domains without leaking them. This is also a great way to provide subdomain permission and expiry scope.
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.
Thanks. I'm currently using subdomains only for trusted services, but I will definitely look towards this direction.
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 :)
That particular problem has an easy technical solution. Just serve a redirect from the one you don't want to use to the one you do. Users can still type whatever the heck they want. You still have a canonical single version for SEO purposes.
I ran into that IE bug a few years ago while working on some PHP code. For those curious what that bug might look like, I did a quick writeup of my findings [1] and posted the solution that I used to work around IE's bad behavior.
1. Yes, I admit, I don't know everything. My old self admittedly knows less than my present self (the post was written 4 years ago), who most likely, I hope, knows less than my future self. I posted the link in the hope that others may find it valuable to see how such a bug might manifest itself.
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.
Assuming you're referring to the "SECURE" flag; this flag merely instructs the browser to only send the cookie over HTTPS (never plain HTTP), but the browser will merrily send it to any server that matches the cookie domain, and the way HTTPS works, this means whoever receives the cookie will be legitimately able to decrypt it.
as long as the translation and redirection is done by the browser somewhat seamlessly (which modern browsers seem to have no problem with on correctly setup websites), I am too. Aesthetically 'www' has never been that pleasant looking.
URLs without www look uglier to me. The www gives you a visual filler space between the cryptic http:// and the domain, but, again, who cares about URLs nowadays? Also, www makes easy to parse out URLs in text. In addition, people will always try www even if your canonical domain is without it resulting possibly in a redundant redirect and/or dual versions of URL being in existence. Lastly, just like www, .com is here to stay. After so much investment in www and .com from advertising, education, etc., don't expect billions to switch away so easily.
Personally I find www. no less cryptic than http://. Additionally http:// is hidden in many browsers these days, so you're left with just {,www.}example.com/ and don't need the filler.
Regarding "who cares about urls nowadays?", clearly the people in this thread making passionate arguments for and against a leading www. care :)
I agree most people probably cannot decode WWW, but, as I said, years have been invested to educate the populace that a web address starts with www. and ends with .com. So, when you see www.hello.com, I don't need to put labels and stuff - people know this is an address. If I put "computer.systems", you won't know unless I label.
"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.
:-)
In English, yes perhaps. Aber auf Deutsch, man sagt "vey vey vey".
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... ;) )
Can someone comment on the SEO implication? I'm no expert,but I have heard it said that the closer your URL is to the http, the higher weight it is given.
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'm pretty sure the only potential hit would be if users are inconsistent in writing links to your site. If everybody wrote www or non-www it'd be exactly the same. If it's mixed, users/bots are sent through a 301.
Meta: I'm personally marveling at how such a laughably simple thing ("www." or no prefix) can become such an unnecessarily complicated technical debate due to archaic infrastructure.
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.
It is possible to do 301 redirects at the registrar level in a way that preserves the full path, including query strings? This is, I'd like to arrange for
example.com/home?a=foo&b=bar
to redirect to
www.example.com/home?a=foo&b=bar
Is there any way to do this without using something more specific like mod_rewrite?
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:
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?"
> 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?
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.
148 comments
[ 2.8 ms ] story [ 221 ms ] threadhttp://no-www.org/
http://www.www.extra-www.org
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.
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?
compared toAnd it does it through an hardcoded alias and not a cname. How clever.
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.
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.
Hosting anything serious on Heroku seems like craziness to me, but perhaps some people have identified uniquely good reasons to do it...
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.
[1] https://en.wikipedia.org/wiki/SRV_record
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.
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.
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 :)
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.
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/
Regarding "who cares about urls nowadays?", clearly the people in this thread making passionate arguments for and against a leading www. care :)
web.example.com
The way it should have been since day one.
"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... ;) )
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.
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.
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
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.