Re: Base URLs

This is mostly just restating what you are saying, but with the same
vocabulary as used within the spec.

> To my mind, a base URL defined within Message Headers is a base URL for
> other URLs within the _headers_. For documents which cannot or do not
> contain a base URL, then it is reasonable for the document to inherit
> any base URL defined in message headers. However, the semantics of the
> document should not be changed simply by ecapsulating it in the headers
> of a transport protocol. Especially as the document will usually be opaque
> to the transport system.

The semantics do not change -- the retrieval context changes.  Since the
base URL defaults to the retrieval context, it has an effect on the default.
This is necessary because the transport protocol DOES define the retrieval
context.

> A specific example: WWW-Authenticate: response headers. The current HTTP spec
> defines the base URL for these headers to be the URL of the requested
> resource. I would prefer the server to be able to choose the base URL with
> a Base: header without always altering the base URL for the document.

Uh, bad example, as that part of the HTTP spec was added in error [:(].
In HTTP, some of the headers are relative to the *requested* URI (which
is an entirely different can of worms and not for discussion here)
as stated in their definition.

The relative URL spec should apply to all Internet protocols, plus
just getting the document from a local disk, but the interpretation of
other headers within those protocols is an issue for those protocol 
working groups and not for this WG.

> So, in fact, I would prefer a completely different interpretation than given
> in 3.1/3.2:
> 
> 1. The base URL is found from the document content. for an HTML document,
>    it is as given in Appendix 10.  For documents which are RFC 822 style
>    messages, the base URL is as given by the Base: header.

Other documents may define their own form of embedded Base -- it is not
a concept limited to HTML.  Since a parser of that document must be aware
of its format, this is not a problem.  Since the base URL can only be
given by the Base: header when the Base: header is present, there is
no point in requiring this for all RFC 822 style messages.

> 2. Otherwise, the base URL of the document is the base URL of the document
>    which encloses this document.

Which is the definition of a composite media type.

> 3. Otherwise the base URL of a document (not enclosed in any other) is defined
>    by the context in which it is retrieved; i.e. its URL.

Yep, unless it was not retrieved by a URL, in which case it is empty.

> Reading the relative URL draft further, I find that it gives this
> interpretation in 3.3 para 2 (but to MIME documents).

Actually, it gives this interpretation for the entire section 3.
The difference is only between what you consider to be a document
and I consider to be a retrieval context.

> Why distinguish message
> headers from other retrieval contexts?

It does not.  Message headers ARE the retrieval context -- the document
is encapsulated inside the message.


......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                                     <fielding@ics.uci.edu>
                     <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

Received on Thursday, 9 February 1995 18:05:53 UTC