8 Understanding URL's
Before we launch into using NetConnect, URLs or Uniform Resource Locators need to be explained. These constitute the most common and efficient method of telling people about resources available via FTP, the World Wide Web, and other Internet services.
A URL uniquely specifies the location of something on the Internet, using three main bits of information that you need in order to access any given object. First is the URL scheme, or the type of server making the object available, be it an FTP, Gopher, or World Wide Web server. Second comes the address of the resource. Third and finally, there's the full pathname or identifier for the object.
This table shows the main URL schemes that you're likely to see.
SCHEME INTERNET PROTOCOL SAMPLE CLIENT
------ ----------------- -------------
ftp File Transfer Protocol AmFTP
gopher Gopher protocol Voyager
http HyperText Transfer Protocol Voyager
mailto Email Microdot-II
news Net News Transport Protocol Microdot-II
If you see a URL that starts with ftp, you know that the file specified in the
rest of the URL is available via FTP, which means that you could use FTP through shell, FTP via Voyager,
or a GUI (based method) FTP client such as AmFTP to retrieve it. If the URL starts with
gopher, use Voyager or another Gopher-supporting client. If it starts with
http, use Voyager or some other Web browser.
NOTE: You can use a Web browser to access most of the URL schemes in the table above, although Web browsers are not necessarily ideal for anything but information on the World Wide Web itself. Web browsers work pretty well for accessing files on Gopher servers and via gateways to WAIS databases, but FTP via a Web browser is clumsy (and may fail entirely with certain types of files, such as self-extracting archives).
After the URL scheme comes a colon (:), which delimits the server type from what comes next. If two slashes (//) come next, they denote that a machine name in the format of an IP address will follow, such as with http://www.amigaworld.com. However, if the URL points at an address in some other format, such as an email address like mailto:active@enterprise.net, the slashes aren't appropriate and don't appear. Basically, all this means is that if there are two slashes after the colon, the URL points at a file available via FTP, Gopher, the Web, or perhaps some other protocol.
NOTE: In some rare circumstances, you may need to use a username and password in an FTP URL as well. A URL with a username and password might look like this:ftp://username:password@domain.name/pub/
The last part of the URL is the specific information you're looking for, be it an email address or more commonly, the path to the directory of the file you desire. Directory names are separated from the machine name by a slash (/). You may not have to specify the path with some URLs if you're only connecting to the top level of the site.
So, for instance, let's dissect a URL that points at the Support page on AmigaWorld server.
http://www.amigaworld.com/support/index.html
First off, the http part tells us that we should use a Web browser to access this URL. Then, www.amigaworld.com is the name of the host machine that's running the Web server. The next part, /support/index.html, is the full path to the file the Web browser shows us, and the path works just like paths do in DOS. /support is a directory, and index.htm is the actual file inside the /support directory.
NOTE: If an FTP or Gopher URL ends with a slash, that means it points at a directory and not a file. If it doesn't end with a slash, it may or may not point at a directory. If it's not obvious from the last part of the path, there's no good way of telling until you go there. Since most Web servers enable the creation of some sort of default file to be served in the absence of a specific file in the URL, it's usually less important for Web users to realise whether or not they're specifying a file or a directory.
All of these details aside, how do you use URLs? Your mileage may vary, but I use them in three basic ways. First, if I see them in email or in a Usenet posting, I often copy and paste the host part into AmFTP (if they're FTP URLs) or the whole thing into Voyager. That's the easiest way to retrieve a file or connect to a site if you have a Amiga-based Internet connection.
Second, if for some reason I don't want to use Voyager (I prefer AmFTP for FTP, for instance), sometimes I manually dissect the URL, as we did with the Support page on the AmigaWorld Web server above, to figure out which program to use and where to go. This method takes more work, but sometimes pays off in the end. You can put a screw in the wall with a hammer, but it's not the best tool for the job.
Third and finally, whenever I want to point people at a specific Internet resource or file available for anonymous FTP, I give them a URL. URLs are unambiguous, and although a bit ugly in running text, easier to use than attempting to spell out what they mean. Consider the example below:
ftp://ftp.amigaworld.com/support/voyager/files/v_test1.lha
To verbally explain the same information contained in that URL, I would have to say something like: "Using an FTP client program, connect to the anonymous FTP site ftp.amigaworld.com. Change directories into the /support/voyager/files/ directory, and once you're there, retrieve the file v_test1.lha" A single URL enables me to avoid such convoluted (and boring) language; and frankly, URLs are in such common use on the Internet, you might as well get used to seeing them right now.
If, after all this, you'd like to learn more about the technical details behind the URL specifications, check out:
http://info.cern.ch/hypertext/WWW/Addressing/URL/Overview.html
NOTE: I find that URLs don't always work well for files stored on Gopher servers, since Gopher allows spaces and other characters that URLs don't accept. Thus, spaces are encoded in Gopher URLs with %20 to indicate that there's a space there.
Go to the previous, next, chapter, table of contents.