- From: David W. Morris <dwm@xpasc.com>
- Date: Wed, 14 Jan 1998 14:58:36 -0800 (PST)
- To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
- Cc: jg@pa.dec.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Wed, 14 Jan 1998, Foteos Macrides wrote: > 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 think we need to decide at this point in time if a revival changes the semantics or offers the server control over precedence. That said, it has finally sunk into my thick skull that there is a semantic difference between Content-location and <base>/Content-base. The origin for relative URL interpretation is acquired from Content-location by parsing off the 'file name piece' where as the origin for <base> is explicit. The <base>/content-base allows an application to utilize a relative base for the whole application and to use relative URL references within the document without consideration of where a particular page appears within the structure. Content-location is an alternative to the request URL and requires that all links within pages be written with full knowledge of their own context. I think Content-base should be removed from the specification but I did want to note that use of Content-location really isn't equivalent. Dave Morris
Received on Wednesday, 14 January 1998 15:07:33 UTC