Since the major use of Internet is for accessing websites, the “www” prefix shouldn’t be needed anymore. It is an archaic holdover from a previous era, one where browser wars meant IE vs. Netscape and where Geocities was the place to be. Thankfully, the folks over at no-www have been aiming to improve this for some time.

So what’s the big deal?

Well, it’s not such a big deal, more just a pet peeve of mine. Most sites out there are thankfully configured well enough so that navigating to “domain.com” just redirects you to “www.domain.com” with no damage done. However, some servers are setup so that navigating to “domain.com” doesn’t work, and this forces you to type in the “www” subdomain before. This really doesn’t make sense in today’s world.

In my opinion, all websites should be set up with the no-www version as the default. Using the “www” subdomain should redirect you to the no-www version, with no harm done. This is known as Class-B compliance, according to the no-www folks, and it’s probably going to be the best way to go for some time, since many people still use the “www”, after having the phrase drilled into their heads during the late 90’s.

So, how to fix it?

If you’ve signed up for hosting from a provider, chances are they’ve already implemented some sort of compliance, but not the optimal type. For example, most hosting providers will automatically redirect the no-www request to the www one. So, under this configuration, someone entering “domain.com” would be redirected to “www.domain.com”. No big deal, but things could be better. After all, the no-www version is shorter and thus requires less typing and less space. Good if you want to save a few cents on your business cards.

Fixing it is a simple effort that takes a minute or so. All you have to do is edit the .htaccess file in the root of your website, if you’re using Apache. Here’s the following directive I’m using.

# BEGIN no-www
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.unitstep\.net$ [NC]
RewriteRule ^(.*)$ http://unitstep.net/$1 [R=301,L]
</IfModule>
# END no-www

The RewriteRule uses a 301 - this is a special HTTP code used to tell of a permanent redirection. Browsers and search engines crawling your site will interpret this as an instruction that your website has permanently moved to the non-www address. This is most important for search engines, so that they know that the no-www version is not just a duplicate or different website than the previous www version. The 301 instruction tells them that the old www version doesn’t exist anymore, and it has been moved to the no-www address.

Taking it a step further, you could also redirect any subdomain to just the root. For example, I also own the domain “peterchng.com”, and wanted to redirect any request to that address, subdomains included, to my main site. Here’s the directives I used.

# BEGIN peterchng.com FORWARD
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(([a-zA-Z0-9]+)\.)*peterchng\.com$ [NC]
RewriteRule ^(.*)$ http://unitstep.net/$1 [R=301,L]
</IfModule>
# END peterchng.com FORWARD

Go ahead, try typing in “who.the.heck.is.peterchng.com” into your browser, and you’ll see it redirects right back to this site.

You’ll want to be careful when using these directives - if you actually do have separate websites on different subdomains, they’ll be inaccessible if you do this! I’ve been using it until I find a use for peterchng.com - or a different use for unitstep.net.

Why all the trouble then?

With all the trouble of going of removing the “www” you may wonder why it was ever used in the first place. Well, IIRC, in the early years of the Internet, websites or HTTP wasn’t the main use. Other services/protocols such as gopher, FTP and telnet were probably a lot more dominant. So, it made sense to set up a separate subdomain that would be used to accept HTTP connections. This would make it easier for users to distinguish between the services offered from a particular domain. However, since HTTP has grown to eclipse those traditional services, the use of www is almost superfluous nowadays.

However, this can create problems if you want to create password-protected directories. Accessing them sometimes doesn’t work because of WordPress’s .htaccess file, however this isn’t a WordPress problem per se, but rather a problem with how Apache has been set up. I ran into this problem - I tried accessing a password-protected directory that I knew had been set up properly, but I kept getting a 404 error and was redirected to my WordPress theme’s 404 page. After a little bit of searching over at the WordPress support boards, I found some solutions that were sort of messy, involving editing WordPress files or adding a lot to the .htaccess file.

However, after looking for a bit more, I found this page, where the author outlines his fix; but later on a comment posted to his site provided me with the fix I wanted - something simple. Though that site deals with TextPattern, another blogging platform, apparently it handles requests in a similar manner to WordPress.

The problem lies with improperly set (usually non-specified) ErrorDocument directives. In this case, the responsible error codes are 401 (Unauthorized) and 403 (Forbidden). These directives are used to tell Apache what document to send or display to the user when each of these error codes are encountered. If these are set to point to a non-existant file, WordPress ends up handling the request - which in these cases, it treats just like a 404. When you try to access a password-protected resource, Apache first sends a 401 (Unauthorized), as a challenge to provide the proper credentials (login/password); if the error directive for this points to non-existant file, then the request is improperly passed on to WordPress and then treated like a 404 here.

To fix it, you need to specify the error directives in your root .htaccess file, which if you have WordPress in the root, is the same file that WordPress uses. If you open it up, you should find WordPress’ rules in there, which will look something like this

# BEGIN WordPress
<ifmodule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</ifmodule>
# END WordPress

Add the following lines to the .htaccess file.

ErrorDocument 401 /<PATH_TO_ERROR_DOCS>/401.html
ErrorDocument 403 /<PATH_TO_ERROR_DOCS>/403.html

Where 401.html and 403.html are the pages you want shown when each of those respective errors are encountered. These should be static pages. (eg. not server-side scripts) This fix worked like a charm for me.