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 Book is Here... and Now On Sale!

The whole site in one document for easy reference!
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
1
2
34
Next Page
URL Length and Complexity Issues
Next Topic/Section

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

Creating and Interpreting Relative URLs

It is for these reasons that URL syntax was extended to include a relative form. In simplest terms, a relative URL is the same as an absolute URL but with pieces of information omitted that are implied by context. Like our “go downstairs” instruction, a relative URL does not by itself contain enough information to specify a resource. A relative URL must be interpreted within a context that provides the missing information.

The context needed to find a resource from a relative URL is provided in the form of a base URL that provides the missing information. A base URL must be either a specific absolute URL, or itself a relative URL that refers to some other absolute base. The base URL may be either explicitly stated or may be inferred from use. The RFCs dealing with URLs define three methods for determining the base URL, which are arranged into the following precedence:

  1. Base URL Within Document: Some documents allow the base URL to be explicitly stated. If present, this specification is used for any relative URLs in the document.

  2. Base URL From Encapsulating Entity: In cases where no explicit base URL is specified in a document, but the document is part of a higher-level entity enclosing it, the base URL is the URL of the “parent” document. For example, a document within a body part of a MIME multipart message can use the URL of the message as a whole as the base URL for relative references.

  3. Base URL From Retrieval URL: If neither of those two methods are feasible, the base URL is inferred from the URL used to retrieve the document containing the relative URL.

Of these three methods, #1 and #3 are the most common. HTML, the language used for the Web, allows a base URL to be explicitly stated which removes any doubt about how relative URLs are to be interpreted. Failing this, method #3 is commonly used for images and other links in HTML documents that are specified in relative terms.

For example, let's go back to the poor slob maintaining “http://www.longdomainnamesareirritating.com/index.htm”. By default, any images referenced from that “index.htm” HTML document can use relative URLs—the base URL will be assumed from the name of the document itself. So he can just say “companylogo.gif” instead of “http://www.longdomainnamesareirritating.com/companylogo.gif”, as long as that file is in the same directory on the same server as “index.htm”.

If all three of these methods fail for whatever reason, then no base URL can be determined. Relative URLs in such a document will be interpreted as absolute URLs, and since they do not contain complete information, they will not work properly.

Also, relative URLs only have meaning for certain URL schemes. For others, they make no sense and cannot be used. In particular, relative URLs are never used for the “telnet”, “mailto” and “news” schemes. They are very commonly used for HTTP documents, and may also be used for FTP and file URLs.

Key Concept: Regular URLs are absolute, meaning that they include all of the information needed to fully specify how to access a resource. In situations where many resources need to be accessed that are approximately in the same place or are related in some way, completely specifying a URL can be inefficient. Instead, relative URLs can be used, which specify how to access a resource relative to the location of another one. A relative URL can only be interpreted within the context of a base URL that provides any information missing from the relative reference.



Previous Topic/Section
URL Schemes (Applications / Access Methods) and Scheme-Specific Syntaxes
Previous Page
Pages in Current Topic/Section
1
2
34
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 (http://www.TCPIPGuide.com)
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.