Many kinds of URLs are defined by the Uniform Resource Locator specification. This post describes some of the more popular URLs and some situations to look out for when using them.
HTTP URLs are by far the most common type of URLs because they point to other documents on the Web. HTTP is the protocol that World Wide Web servers use to communicate with web browsers.
HTTP URLs follow this basic URL form:
If the URL ends in a slash, the last part of the URL is considered a directory name. The file that you get using a URL of this type is the default file for that directory as defined by the HTTP server, usually a file called index.html . If the web page you’re designing is the top-level file for all a directory’s files, calling it index.html is a good idea. Putting
such a file in place will also keep users from browsing the directory where the file is located.
You also can specify the filename directly in the URL. In this case, the file at the end of the URL is the one that is loaded, as in the following examples:
Using HTTP URLs such as the following, where foo is a directory, is also usually acceptable:
FTP URLs are used to point to files located on FTP servers—usually anonymous FTP servers; that is, the ones that allow you to log in using anonymous as the login ID and your email address as the password. FTP URLs also follow the standard URL form, as shown in the following examples:
Because you can retrieve either a file or a directory list with FTP, the restrictions on whether you need a trailing slash at the end of the URL aren’t the same as with HTTP. The first URL here retrieves a listing of all the files in the foo directory. The second URL retrieves and parses the file homepage.html in the foo directory.
Although your browser uses FTP to fetch the file, if it’s an HTML file, your browser will display it just as it would if it were fetched using HTTP. Web browsers don’t care how they get files. As long as they can recognize the file as HTML, either because the server explicitly says that the file is HTML or by the file’s extension, browsers will parse and display that file as an HTML file. If they don’t recognize it as an HTML file, no big deal. Browsers can either display the file if they know what kind of file it is or just save the file to disk.
All the FTP URLs in the preceding section are used for anonymous FTP servers. You also can specify an FTP URL for named accounts on an FTP server, like the following:
In this form of the URL, the username part is your login ID on the server, and pass is that account’s password. Note that no attempt is made to hide the password in the URL. Be very careful that no one is watching you when you’re using URLs of this form—and don’t put them into links that someone else can find! word
Furthermore, the URLs that you request might be cached or logged somewhere, either on your local machine or on a proxy server between you and the site you’re connecting to. For that reason, it’s probably wise to avoid using this type of non-anonymous FTP URL altogether . You may find yourself using non-anonymous FTP to upload your HTML files (or other files related to websites) to a web server in order to publish them. Normally, it’s best to connect to the FTP server using a dedicated FTP client rather than the browser.
Mailto URLs are used to send electronic mail. If the browser supports mailto URLs, when a link that contains one is selected, the browser will open a new outgoing email your default email application and send that message to the address in the link when you’re done. Depending on how the user’s browser and email client are configured, mailto links might not work at all for them.
The mailto URL is different from the standard URL form. It looks like the following:
Here’s an example:
Unlike the other URLs described here, the mailto URL works strictly on the client side. The mailto link just tells the browser to compose an email message to the specified address. It’s up to the browser to figure out how that should happen. Most browsers will also let you add a default subject to the email by including it in the URL like this:
When the user clicks the link, most browsers will automatically stick Hi there! in the subject of the message. You can also define Cc and Bcc addresses like this:
Some even support putting body text for the email message in the link with the body=query. Then you can combine them all together, like this :
mailto:email@example.com?subject=Hi firstname.lastname@example.org&body=Body text.
File URLs are intended to reference files contained on the local disk. In other words, they refer to files located on the same system as the browser. For local files, URLs have an empty hostname (three slashes rather than two):
You’ll use file URLs a lot when you’re testing pages you’ve created locally, although it’s easier to use the browser’s “Open File” functionality or drag and drop to open local files in your browser than it is to type in a file URL. Another use of file URLs is to create a local startup page for your browser with links to sites you use frequently. In this instance, because you’ll be referring to a local file, using a file URL makes sense.
The problem with file URLs is that they reference local files, where local means on the same system as the browser pointing to the file—not the same system from which the page was retrieved! If you use file URLs as links in your page, and someone from else where on the Internet encounters your page and tries to follow those links, that person’s browser will attempt to find the file on her local disk (and generally will fail). Also, because file URLs use the absolute pathname to the file, if you use file URLs in your page, you can’t move that page elsewhere on the system or to any other system.
If your intention is to refer to files that are on the same file system or directory as the current page, use relative pathnames rather than file URLs. With relative pathnames for local files and other URLs for remote files, you shouldn’t need to use a file URL at all.