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

RE: MUST use Content-Base

From: David W. Morris <dwm@xpasc.com>
Date: Tue, 13 Jan 1998 00:10:56 -0800 (PST)
To: Yaron Goland <yarong@microsoft.com>
Cc: 'Scott Lawrence' <lawrence@agranat.com>, Henrik Frystyk Nielsen <frystyk@w3.org>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.GSO.3.96.980113000130.1790J-100000@shell1.aimnet.com>


On Mon, 12 Jan 1998, Yaron Goland wrote:

> The only way this thing can be a must is if we change the protocol number.
> [Insert standard Henrik lecture here =)]

rom the fence, I've slowly moved to the DELETE completely opinion.

Part of my reasoning is that I can't think of any content where 
the addition of Content-base couldn't be handled by a possible
slight extention to the data format.

The remainder is that I'm becoming convinced that the functionality
provided is inadequate and perhaps the order of inheritence is the
reverse of the most useful.  I use the HTML <BASE> tag today for
two reasons:
   a.  Add image references to error content generated by proxies w/o
       making all images absolute URLs
   b.  Create an internal document name space which is all relative
       to the same origin, not the document origin. This makes it
       possible to move pages within a hieararchy w/o re-writing
       internal links.
In both of these situations, I've used dynamically generated HTML
so inserting a BASE tag was more efficient than finding and fixing
every link using the site scripting language.

With the background, what I would find more useful would be to
over-ride the internally specified document base with one added by
the server.  Such an option would allow easy move of my document
collections to other locations.

This is the opposite form of inheritence from that currently specified.
I'm not proposing that the current form be eliminated, rather I'm 
attempting to prove by example that the current specification misses
a major subset of the problem space.  Thus, it is better to 
remove it completely until it can be thought out more thoroughly
and specified with more functionality.

Dave Morris
Received on Tuesday, 13 January 1998 00:13:39 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:10 EDT