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". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||^$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 Book is Here... and Now On Sale!

Get The TCP/IP Guide for your own computer.
The TCP/IP Guide

Custom Search

Table Of Contents  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)
                9  Uniform Resource Locators (URLs)

Previous Topic/Section
URL Schemes (Applications / Access Methods) and Scheme-Specific Syntaxes
Previous Page
Pages in Current Topic/Section
Next Page
URL Length and Complexity Issues
Next Topic/Section

URL Relative Syntax and Base URLs
(Page 3 of 4)

Practical Interpretation of Relative URLs

The description above probably seems confusing, but relative URLs are actually fairly easy to understand, because they are interpreted in a rather “common sense” way. You simply take the base URL and the relative URL, and you substitute whatever information is in the relative URL for the appropriate information in the base URL to get the resulting equivalent absolute reference. In so doing, you must “drop” any elements that are more specific than the ones being replaced.

What do I mean by “more specific”? Well, most URLs can be considered to move from “most general” to “most specific” in terms of the location they specify. As you go from left to right, you go through the host name, then high-level directories, subdirectories, the file name, and optionally, parameters/query/fragment applied to the file name. If a relative URL specifies a new file name, it replaces the file name in the base URL, and any parameters/query/fragment are dropped as they no longer have meaning given that the file name has changed. If the relative URL changes the host name, the entire directory structure, file name and everything else “to the right” of the host name “goes away”, replaced with any that might have been included in the new host name specification.

This is hard to explain in words but easy to understand with a few examples. Let's assume we start with the following explicit base URL:

Table 224 shows some example of relative URLs and how they would be interpreted.

Table 224: Relative URL Specifications and Absolute Equivalents

Relative URL

Equivalent Absolute URL



The URL is the same except that the bookmark is different. This can be used to reference different places in the same document in HTML.

(Technically, the URL has not changed here, since the “fragment” (bookmark) is not part of the actual URL. A Web browser given a new bookmark name will usually not try to re-access the resource.)


The same file but with a different query string. Note that the bookmark reference from the base URL is “stripped off”.


Here we have referred to a file using the name “file2”, which replaces “file1” in the base URL. Here both the query and bookmark are removed.


Since a single slash was included, this means “file2” is in the root directory; this relative URL replaces the entire <url-path> of the base URL.


The pair of dots refers to the parent directory of the one in the base URL. Since the directory in the base URL is “dir1/subdir1”, this refers to “dir1/”.


Specifies that we should go up to the parent directory to find the file “file2” in “dir1”.


Go up one directory with “..”, then enter the subdirectory “subdir2” to find “file2”.


Same thing as above but going up two directory levels, then down through “dir2” and “subdir2” to find “file2”.



Two slashes means that “file2” replaces the host name, causing everything to the right of the host name to be stripped. This is probably not what was intended, and shows how important it is to watch those slashes. J


Here everything but the scheme has been replaced. (In practice this form of relative URL is not that common—the scheme is usually included if the site name is specified, for completeness.)


Here we replace the file name, query name and bookmark name.

Using a new scheme forces the URL to be interpreted as absolute.

Previous Topic/Section
URL Schemes (Applications / Access Methods) and Scheme-Specific Syntaxes
Previous Page
Pages in Current Topic/Section
Next Page
URL Length and Complexity Issues
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $

Home - Table Of Contents - Contact Us

The TCP/IP Guide (
Version 3.0 - Version Date: September 20, 2005

Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.