May 1, 2002

Removing the www

Jeff Lash writes Removing the Ws from URLs over at Web Word. Jeff has some good reasons behind not needing the "Ws", but you must really understand your user's browser use before removing the Ws. You see some browsers do not respond to "vanderwal.net", they need the "www". Microsoft IE 5 and above and Netscape 6 and above understand that a person is most often trying to find a Website if they type a link into their Web browser. Older browsers do not make this assumption and the user must type the "www" and often also type the "http://" to get to the site. This is much more confusing. The administrator for the site must also ensure their DNS tables that route URLs to the site, do not require the "www". I personally find the lack of the "www" problematic as many browsers now also can handle FTP services and become the default viewer for the file structures when FTPing. This requires typing "ftp" rather than "www" in front of the "www". (I have used my rationing of " marks so I must stop)


Posted Comments

You make a number of good points, but I think you have to realize the context in which I'm talking about this. FTP through the browser: Yes, this is possible. It's been possible for at least 5 years (I remember using it right when IE4/PC came out), possibly longer. Still, it is used very rarely, especially by the "average" user (whatever that means). Nearly all traffic is HTTP, and thus I feel it makes sense to assume someone is looking for a web site with "domainname.com"; most modern browser support that. Also, when FTP-ing through the browser, not only is "ftp.domainname.com" needed, but "ftp://" rather than "http://". So, in this sense, whether you use www or not doesn't matter, because the whole protocol will need to be switched, not just the domain prefix. Another important point is that most of the time, people don't get to a site by typing the domain name or URL in. They use a search engine or link from another page. In those cases, the URL will include the "http://" prefix, so whether or not you use the www makes no difference in how their browser works. For people who are using browsers that require them to put the "www" before a domain name (i.e. www.vanderwal.net), well, if they use the www, they will still be able to access the site. They will connect to the server, at which point they'll be redirected to http://vanderwal.net. The redirection needs to include the http:// (that's an apache rule, I believe), so, again, whether the www is present or not makes no difference. From what I understand, the last browsers to require that a person manually type "http://" were v2; people still using v2 browsers would have to be used to typing http:// in front of every URL, so whether they type http://www.vanderwal.net or http://vanderwal.net, it doesn't matter, they'll end up in the same place. I'd venture to guess that most people don't realize there is a difference between www.domainname.com and domainname.com. They either always include the Ws or always don't. I'd imagine that if they always include Ws before domain names, they probably also always include Ws before subdomains (I've seen this happen quite a bit), so you'd better make sure that www.dev.vanderwal.net works too. I've gone way over my limit with " marks and probably am in " debt, so I'll stop now..

Jeff, I largely agree. One of the version of Netscape 4, if recollection serves me right (from 6 months ago I had that verions running as my test NS4 test browser), if I typed a URL without the "www" I had to type the http://. With this bowser if I typed the www I did not need the http://. This is not the current case with NS 4.08, nor 4.73 and above. The case for having www.dev.vanderwal.net, is a serious problem with router tables and DNS configurations. I have had my Cisco networking folks strongly urge the leading www from subdomians like dev.vanderwal.net. This added level slows the routing process, which I now wonder if the lack of a www or a subdomain speeds routing. I will check that one out and get back to you.

Web Mentions

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License.