Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Key Applications and Application Protocols            9  TCP/IP Application Layer Addressing: Uniform Resource Identifiers, Locators and Names (URIs, URLs and URNs)

URL Obscuration, Obfuscation and General Trickery 1 2 3 TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)

“HTTP 404 - NOT FOUND”

Have you ever tried to access a Web site or other Internet resource, only to see those dreaded words appear? You probably have, and in seeing them, you have experienced first-hand one of the most common problems with Uniform Resource Locators (URLs).

URLs specify a resource using two key pieces of information: the resource's location, and a method by which the resource may be accessed or retrieved. This focus on the means of access for the resource makes URLs very practical, in that the URL usually contains all the data we need to use the resource. This is why URLs are so widely used today. However, this “access orientation” also means that URLs have a number of serious limitations.

The main difficulty with URLs is that since they describe a resource based on its location, they tie the resource and its location together inextricably. While this may not seem to be a big deal, it is actually a fairly serious matter in a number of ways, because a resource and its location are not the same thing. It is only because most Internet resources rarely change location that we don't notice this issue more often with URLs.

Suppose that your name is Joe Xavier Zachariah and you live at 44 Glendale Crescent in Sydney, Australia. If someone asked you who you were, would you say “Joe Xavier Zachariah”, or “the man living at 44 Glendale Crescent in Sydney, Australia”? Almost certainly, the former; but a URL would be like describing yourself as a “resource” using the latter description.

Since we realize that Mr. Zachariah is obviously not always going to be at 44 Glendale Crescent, we know that describing him using just a location is not sufficient. The same thing occurs with Internet resources when they are identified using only location.

However, the problem with Internet resources and URLs goes beyond just the matter of movement. Consider a situation where a particular resource is very popular; we might want to duplicate the same resource in multiple locations. Using URLs, we would need a different identifier for each copy of the resource, even though each copy is the same. Again, the problem is that we are not identifying the resource itself but rather the place where it can be found.

URL Obscuration, Obfuscation and General Trickery 1 2 3 TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)