W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Re: MUST use Content-Base

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Wed, 14 Jan 1998 17:25:02 -0500 (EST)
To: jg@pa.dec.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5182
jg@pa.dec.com (Jim Gettys) wrote:
>>  From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
>(material elided...)
>>  When I was rewriting the URI specification and arguing with the MHTML
>>  group, I came to the conclusion that Content-Base is not needed provided
>>  that Content-Location is implemented as specified.  The reasoning was
>>  similar to what Dave Morris mentioned: the only person capable of knowing
>>  whether or not the embedded references in a document are relative to
>>  some other namespace is the document creator, and they are better-off
>>  making that distinction within the document.  Granted, some formats may
>>  not have the equivalent of HTML's BASE, but I would argue that those
>>  formats are very unlikely to contain relative references.
>Do others agree with Roy's analysis?  Is this true in the face of
>negotiated resources, where Content-Location might be used to tell you
>where the underlying version is found? 
>The minimalist in me says if we don't actually need a mechanism, or a
>different mechanism we do need can be used to solve a problem, we shouldn't
>have it...
>And we haven't heard other opinions (e.g. lynx, etc....).  I'd like to hear
>from others who've formed opinions.

	I'm away for most of this month, with only occassional Internet
access, so I can't participate in any lengthy WG discussions, but happen
to be logged in here today, so I'll summarize my opinions as someone
associated with Lynx, based on what I've read so far in this thread.

	Lynx long ago implemented use of Content-Base or absolute
URLs in Content-Location headers as a means of specifying the base
for resolving partial references when a BASE element is not present
in HTML documents.  I disgree that if retained in the HTTP/1.1
Draft Standard support for it by clients should be considered optional,
but have no strong opinion on whether it should be retained or deleted.
If deleted, this should not be with the intention of later reviving
it with a change in rules such that it takes precedence over an actual
BASE element in the entity-body.

	I don't know if ability to specify the base via an HTTP header
is more important for XML than for HTML, but it doesn't seem to be a
critical need for HTML accessed via HTTP, and I've never seen either
Content-Base or Content-Location used seriously for that purpose
with simple (non-multipart) HTML documents.  Both Dave's and Roy's
posts seem to reflect thoughts about such simple HTML documents.
The use of these headers for multipart documents should correspond
as well as possible with the MHTML-WG's specs, and those seem to
be undergoing radical change, such that I don't yet have any firm
opinions in that regard.

	I doubt that anyone else associated with Lynx has strong
opinions about these matters.  Klaus might have, but is also
Internet-deprived this month.

	My only schtick this month is that the URL -> URI draft
state explicitly that only one unescaped hash ('#") is allowed
in URIs, which if present must be a fragment delimiter, and
that the direction of parsing for it is irrelevant (explicitly,
with words in the draft, not just posts to WG lists :).


 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
Received on Wednesday, 14 January 1998 14:32:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC