thought of in terms of layers, where the innermost defined base URL
   has the highest precedence.  This can be visualized graphically as:

      .----------------------------------------------------------.
      |  .----------------------------------------------------.  |
      |  |  .----------------------------------------------.  |  |
      |  |  |  .----------------------------------------.  |  |  |
      |  |  |  |   (3.1) Base URL embedded in the       |  |  |  |
      |  |  |  |         document's content             |  |  |  |
      |  |  |  `----------------------------------------'  |  |  |
      |  |  |   (3.2) Base URL of the encapsulating entity |  |  |
      |  |  |         (message, document, or none).        |  |  |
      |  |  `----------------------------------------------'  |  |
      |  |   (3.3) URL used to retrieve the entity            |  |
      |  `----------------------------------------------------'  |
      |   (3.4) Base URL = "" (undefined)                        |
      `----------------------------------------------------------'

3.1.  Base URL within Document Content

   Within certain document media types, the base URL of the document can
   be embedded within the content itself such that it can be readily
   obtained by a parser.  This can be useful for descriptive documents,
   such as tables of content, which may be transmitted to others through
   protocols other than their usual retrieval context (e.g., E-Mail or
   USENET news).

   It is beyond the scope of this document to specify how, for each
   media type, the base URL can be embedded.  It is assumed that user
   agents manipulating such media types will be able to obtain the
   appropriate syntax from that media type's specification.  An example
   of how the base URL can be embedded in the Hypertext Markup Language
   (HTML) [3] is provided in an Appendix (Section 10).

   Messages are considered to be composite documents.  The base URL of a
   message can be specified within the message headers (or equivalent
   tagged metainformation) of the message.  For protocols that make use
   of message headers like those described in RFC 822 [5], we recommend
   that the format of this header be:

      base-header  = "Base" ":" "<URL:" absoluteURL ">"

   where "Base" is case-insensitive and any whitespace (including that
   used for line folding) inside the angle brackets is ignored.  For
   example, the header field





 
RFC 1808           Relative Uniform Resource Locators          June 1995


      Base: <URL:http://www.ics.uci.edu/Test/a/b/c>

   would indicate that the base URL for that message is the string
   "http://www.ics.uci.edu/Test/a/b/c".  The base URL for a message
   serves as both the base for any relative URLs within the message
   headers and the default base URL for documents enclosed within the
   message, as described in the next section.

   Protocols which do not use the RFC 822 message header syntax, but
   which do allow some form of tagged metainformation to be included
   within messages, may define their own syntax for defining the base
   URL as part of a message.

3.2.  Base URL from the Encapsulating Entity

   If no base URL is embedded, the base URL of a document is defined by
   the document's retrieval context.  For a document that is enclosed
   within another entity (such as a message or another document), the
   retrieval context is that entity; thus, the default base URL of the
   document is the base URL of the entity in which the document is
   encapsulated.

   Composite media types, such as the "multipart/*" and "message/*"
   media types defined by MIME (RFC 1521, [4]), define a hierarchy of
   retrieval context for their enclosed documents.  In other words, the
   retrieval context of a component part is the base URL of the
   composite entity of which it is a part.  Thus, a composite entity can
   redefine the retrieval context of its component parts via the
   inclusion of a base-header, and this redefinition applies recursively
   for a hierarchy of composite parts.  Note that this might not change
   the base URL of the components, since each component may include an
   embedded base URL or base-header that takes precedence over the
   retrieval context.

3.3.  Base URL from the Retrieval URL

   If no base URL is embedded and the document is not encapsulated
   within some other entity (e.g., the top level of a composite entity),
   then, if a URL was used to retrieve the base document, that URL shall
   be considered the base URL.  Note that if the retrieval was the
   result of a redirected request, the last URL used (i.e., that which
   resulted in the actual retrieval of the document) is the base URL.

3.4.  Default Base URL

   If none of the conditions described in Sections 3.1 -- 3.3 apply,