Re: Recursive look up of base in outer headers

At 00.08 -0500 97-09-04, Pete Resnick wrote:
> Content-Type: multipart/related
> Content-Base: foo://bar/biff/
>     Content-Type: multipart/mixed
>     Content-Location: blah://blee/
>         Content-Type: text/html
> What is the base for the text/html, which has neither Content-Location nor
> Content-Base? Is it <blah://blee/> (the base we use for its parent since it
> has not Content-Base) or is it <foo://bar/biff/> (the specific base of its
> parent's parent)?

The latest draft says that a base in an absolute Content-Location in an
inner heading has precedence over a Content-Base in a heading further out.
Below is the text in the draft I sent in a few days ago
(, see also

--- ---

5. Base URIs for resolution of relative URIs

Relative URIs inside contents of MIME body parts are resolved relative to a
base URI using the methods for resolving relative URIs described in
[RELURL]. In order to determine this base URI, the first-applicable method
in the following list applies.

(a) There is a base specification inside the MIME body part containing
    the link which resolves relative URIs into absolute URIs. For
    example, HTML provides the BASE element for this.

(b) There is a Content-Base header (as defined in section 4.2), in the
    immediately surrounding content heading, specifying the base to be

(c) There is a Content-Location header in the immediately surrounding
    heading of the body part which contains an absolute URI and can
    then serve as the base in the same way as the requested URI can
    serve as a base for relative URIs within a file retrieved via HTTP

(d) Step (b) and (c) can be repeated recursively on Content-Base and
    Content-Location headers in surrounding multi-part headings.
    However, a base from an absolute Content-Location in an inner
    heading takes precedence over a base from a Content-Base or a
    Content-Location in a surrounding heading.

When the methods above do not yield an absolute URI matching of two
relative URIs against each other can still be done for matches within a
multipart/related. This matching is done as if they had been given as base
an imaginary URL "This_message:/", which exists for the sole purpose of
resolving relative references within a multipart entitity.

Jacob Palme <> (Stockholm University and KTH)
for more info see URL:

Received on Thursday, 4 September 1997 08:16:55 UTC