In modern webbrowsers is there any point in putting www infront of a url that uses it?

Question

When going to www.facebook.com or www.cbc.ca is there any benefit or difference made by omitting the www?

EDIT: so it could be a problem if www is omitted but not automatically added, could it ever be a problem if www is added but not required?

Answer 1

In modern webbrowsers is there any point in putting www infront of a url that uses it? When going to www.facebook.com or www.cbc.ca is there any benefit or difference made by omitting the www?

It usually doesn’t, but it could.

This has nothing to do with the browser; it has to do with the web-server. The web-server is a computer (or even multiple computers) which receive queries for web-pages and send the appropriate data. A URL includes several parts, one of which is the name or address of the web-server.

Many companies host more than just a web-server, they may also run an FTP-server, a database-server, a mail-server, and so on. These could be hosted from the same machine as the web-server or on different machines.

In the past, it was common to specify the difference via a prefix for consistency. So for example, Acme Industries might buy the domain-name acme.org, then set up one or more computers to host the different service they have. When you want to use one of the services, you enter the appropriate host name:

 www.acme.org - Acme’s web-site
 ftp.acme.org - Acme’s file server
 sql.acme.org - Acme’s database server
 pop.acme.org - Acme’s incoming mail server
smtp.acme.org - Acme’s outgoing mail server

So why does it still work without www.? Because most web-servers allow you to accept different URLs and redirect them as necessary. For the convenience of users, most companies and organizations set up a rule to have have the web-server handle connections to the hostname on port 80 (the “web port”) or redirect it to another system if the web-server is a different machine.

Differentiating the service or machine being accessed can also be done through the port, but it requires specifically including it in the name, so it’s not really any better than using prefixes:

acme.org:80     - web-server
acme.org:21     - file server

Sometimes the scheme can perform this function:

http://acme.org - web-server
ftp://acme.org  - file server

Using schemes works as well and can be done automatically using the appropriate software (e.g., a browser would add http://, an email client would add pop://, etc.), but there are not official schemes for every type of server that can exist, and inventing one is not ideal because it would require software to support it.

It’s becoming less and less necessary to include www., but it is not universal and some sites still require it because helps keep things organized.

Answer 2

Yes and no. The www is 'just' a subdomain thats used for websites commonly, and unfortunately not all companies set up their second level domain to be accessible without it.

If the address you're going to has a www subdomain and its not set up to allow its second level then its necessary. Else no.

As for how you set it up, there's both schools of thought that www is not needed and that it does. There's little reason not to set up your domain records to point at the www less second level domain. www is probably obsolete in this day and age but it dosen't hurt to have it. In my case, I personally don't have www domains but thats due to laziness more than anything else.

Answer 3

Usually, companies redirect "domain.com" to "www.domain.com", but that's not a required standard, and it's not always followed.

While you do most of your internet interaction through a web browser, there's other stuff on the Internet besides web pages. While nearly all of this is wrapped up in web pages today, there's still FTP, Telnet, Gopher, news servers, mail servers, SIP (voice over IP) and a few other fun protocols. Anyone remember Finger?

Since all of these services were different, each had a unique hostname assigned to it by convention: you could always count on finding an FTP server at ftp.netscape.net, their gopher server was gopher.netscape.net, and so on.

Of course, in the 80's and early 90's, a server computer cost more than a luxury car. So www.company.com and ftp.company.com probably pointed to the same place, since the entire company would have just a single Internet server.

Then something big happened. In the 90's: server computers got cheaper, and expensive mainframes and minicomputers gave way to commodity systems that cost less than a weekend at Disneyland. Any desktop machine could be a web server, thanks to free Linux, and people started building out their server farms with multiple PC's. Today, you can build a web server for less than $100, and store it in a soda can (hopefully an empty one.)

So the Internet exploded: Facebook today gets more hits in one day than the entirety of the Internet did in 1995. So we use more than one server to handle web requests: entire groups of computers these days will respond to a single host name, thanks to the magic of load balancing, and the Internet seems to have settled on a standard of doing all of our Internet work through a web browser.

What this means is that www.domain.com is no longer on the same computer as ftp.domain.com. So where do we send requests to the "naked" domain of "domain.com"?

Today, people think of "the web" as "the Internet", and so they use a browser for everything they do. That's convenient, since having separate programs for downloading files, reading news, checking email, reading blogs, and checking the weather can be a real pain. It also brings up questions like "why do we have www in front of web pages?" This means that we can usually get away with assuming that a request for a naked domain is the same as a request for that domain's www server.

So now, most companies will respond to naked requests by redirecting "domain.com" to "www.domain.com". However, there's no standard that requires it, and you'll frequently find that small domains hosted on server farms won't respond to naked domains that way. (For example, one hosting company I used dropped users to the hosting company's landing page when someone typed just "mydomain.com".)

Luckily for the lazy among us, there's a keyboard shortcut in most browsers that lets you shorten the process even more: just type "company", press Control-Enter, and the browser expands it to "www.company.com".

Answer 4

The domain name part of URLs is read backwards. So www.example.com/index.html is actually like com/example/www/index.html in terms who is "inside" who.

Many sites have a www subdomain, but they may also have other subdomains such as ftp, secure, members, forum, us, fr, china and so on. These are all different from each other, and www.example.com is also a different address from example.com (there's no rule saying example.com should be interpreted as www.example.com and not, for instance, store.example.com).

What happens if I don't add the www?

Usually, nothing. People who run websites realize that everyone is going to forget it all the time, so they configure their site to make www.example.com and example.com point to the same place (by redirecting).

Once in a blue moon you may run into a site that won't work without the www because the person running it didn't do the configuration. So you will be able to access http://www.example.com but http://example.com will return an error.

What happens if I put in an extra www?

Same as above, except switch around which URL works and which doesn't.

Also, technically, you are supposed to include the http:// part as well, so any address you enter is incomplete anyway whether you enter the www or not. The browser will have to infer what you meant in both cases - so it may infer that the www was meant to be included.

Sites where the www matters are very rare nowadays, but I know I've encountered a few in the past 2-3 years. I can't remember what they were right now.

Answer 5

There is a lot of rubbish being talked here.

The thing containing a "www." (or not) is a DNS name and hence subject to some very specific rules. Notably that you can't have two names of different record types unless one of the records is an A or an AAA record. If you want to receive emails at example.com then you must have an MX record for example.com. But browsers won't search for MX records when trying to find a website, they only look for CNAME, AAA and A records. So if a site has an MX record it cannot have a CNAME with the same name. The problem with A records is that they only point to a single host - and the layer of abstraction provided by CNAMEs is important for load balancing and disaster recovery. Cloudflare (for example) allow you to configure DNS records as if a CNAME were permitted and convert this to an A record on the fly.

Answer 6

As a sysadmin, if you want to use CDN Services for speed up your web service, you can't use any combination of dns rules together.

To use a CDN, you must use a dns Cname, so you need to create a Cname for acme.org, but if you want to receive Mail with [e-mail], you can't have a cname for acme.org. Then you must use a subdomain www for the web server, so as sysadmin is mandatory to have a www record.

Modern browsers hidden to you the need for write the www part, but this part can be necessary for a website with a high visit rate. The rules for internet are old, but are our rules.

Answer 7

There are the issues dealing with the variety of smartphones and small-screened tablet devices (sorry, but I cannot force myself to type the iWords) that are now browsing the web.

Generally the prefixes of mobi. or m. are used (instead of www.) in order to provide web pages that are tailored to the smaller screens.

Who hasn't run into the issue of trying to navigate a large scaled web page on a small device (scroll, scroll, scroll)?

Answer 8

Building on what has been mentioned already, most corporate/private servers will automatically redirect to WWW. On the other hand many, if not most, .GOV and .MIL sites will not. In those cases you usually receive one of many error messages. These sites also usually do not automatically redirect to HTTPS: from HTTP: even when needed.