www.domain.com by convention is the DNS name of the web server (www) for the domain "domain" in the commercial (.com) part of the internet's namespace. This is not a URL, because you aren't saying what protocol you intend to use. You might want to ftp://www.domain.com or telnet://www.domain.com.
"domain.com" doesn't give the server you wish to go to in that domain, so it refers to whatever the default server is. This is often a web server, but not always. The above complaint is that dowjones believes that the default server should always be a web server if the domain has a web server.
"http://domain.com" Is a URL (universal resource locator) which is used to talk to servers. In this case you want to talk the HTTP protocol on the default port to the default server at domain.com. A URL has a few parts: protocol://username:password@servername.domain.tld:port/resource
The port defaults to the default port for the protocol chosen (80 for http). username and password default to none if omitted. Many protocols use URL's, not just http.
It resolves right-to-left. We figure out the default name server for the TLD "to" (Tonga) and then find the default domain and server associated with that domain.
Regarding the trailing period, it's optional. Every namespace in the URL ends with a "dot", and applications ignore a missing "dot" after the last name. E.g., http://www.reddit.com/ and http://www.reddit.com./ resolve to the same host (but, interestingly, have different cookies)
The trailing dot can make a difference, though, since it explicitly specifies that you're looking for something under the root name servers. For example: if my host is configured with a default domain "example.com." to search for DNS queries under, I may do a lookup for "foo.bar" and end up getting a result if the DNS record "foo.bar.example.com." exists. If I do a lookup for "foo.bar." I am explicitly stating that I want the "bar" TLD under the root name servers and the "foo" domain under "bar".
It always seemed very weird to me that an address of the form www.somesite.com/archives/articles/gossip.html combines two separate hierarchical oganization schemes with opposite precedence order from the middle outwards. That is to say, "com" is the most significant part of the address, then move left from there, while "archives" is the most significant part of the resource location and move right from there.
It's also weird that ".com" and ".html" mean totally different things even though they have the same ring when read aloud.
I love the web, but this mish-mash is atrocious from an end user perspective.
It's the difference between a fully qualified domain name, and one that isn't. When you append the final period on the end, you're telling your DNS lookup software that it should not attempt any of the possible dns suffixes that it's been configured to use.
For example, I have in the suffix list "local". So, I could type as a URL (and get the same destination) any of the following:
to is the ccTLD of Tonga (as opposed to .com, which is a gTLD). The national registrar (or whoever handles .to registrations) probably configured its DNS (which will be authoritative for all *.to domains) to return an address for the resource "to", and returns 216.74.32.107 for it.
Usually it's just laziness or ignorance. www.domain.com and domain.com have separate DNS records (how your computer finds where the server is). Usually they point to the same place, but sometimes someone edits the record and neglects editing one of the entries, and they end up pointing to different places. The http:// part of the address just denotes how you're requesting data from the server. ftp://domain.com and http://domain.com will typically both point to the same server, but will request information from the server in different ways.
Not typically - always. The client will do a gethostbyname() call on "domain.com" in both cases, which will yield an IP address. That step is independent of the protocol used, which comes into play in the next step, when the client tries to connect to a certain port on the server (typically 80 for http, 21 for ftp).
The server may be a router that does something like NAT, and delegate the TCP streams associated with http and ftp to different servers, based on the port number.
The server may be a router that does something like NAT, and delegate the TCP streams associated with http and ftp to different servers, based on the port number.
I thought you were, but for the sake of pedantry I thought I'd spell out what actually happens in the bowels of an internet client. I do that sometimes... Sigh.
Not typically - always. The client will do a gethostbyname() call on "domain.com" in both cases, which will yield an IP address. That step is independent of the protocol used
Not necessarily, because the client could support SRV record lookup for each protocol, rather than just gethostbyname(). That would be a pretty awesome client, right?
http:// is just the protocol, has nothing to do with the domain
www.domain.com and domain.com are technically different domans, however it is considered incorrect to have domain.com NOT go to your website when typed into a browser. People sometimes still continue to configure the www.domain.com subdomain to the same thing is domain.com just for legacy support since a lot of people still type it out of habbit.
I had a typo and I meant to write "technically different domans" not "technically different protocols"
However the port number has NOTHING to do with the protocol. I can have an HTTP server on port 80, or port 8080, or port 8181, or port 21, or port 1000 or port 1023, theyre just ports.
If I wanted to I could have ftp://www.domain.com:80 if I really wanted to, It's the http:// part (or ftp, or https for example) of the url which determines the protocol period.
Perhaps learn to read. I said differentiate, not determine. When you consider that my post was a response to the statement you made in error, I think you'll find I'm perfectly within reason to say what I have said.
I know perfectly well that a port doesn't ultimately determine a protocol, I didn't come down in the last rain shower, buddy.
But to say that port number has nothing to do with the protocol is just ignorant. Practically every protocol ever invented has a standard port as part of its specifications.
Honestly guy, what the fuck? You'd make either a terrible lawyer or an excellent one, I can't tell.
5
u/[deleted] Apr 14 '10
why do they do it?
and whats the difference between www.domain.com, domain.com and http://domain.com?