Re: MUST use Content-Base
Foteos Macrides (MACRIDES@sci.wfbr.edu)
Wed, 07 Jan 1998 12:49:46 -0500 (EST)
koen@win.tue.nl (Koen Holtman) wrote:
>Scott Lawrence:
>>
>> In the course of our interoperability testing, we have found that
>> many browsers ignore the Content-Base header field (see
>> http://test11.agranat.com/basetest/). The spec now reads:
>>
>> ================
>> 14.11 Content-Base
>>
>> The Content-Base entity-header field may be used to specify the base URI
>> for resolving relative URLs within the entity.
>>
>> Content-Base = "Content-Base" ":" absoluteURI
>>
>> If no Content-Base field is present, the base URI of an entity is
>> defined either by its Content-Location (if that Content-Location URI is
>> an absolute URI) or the URI used to initiate the request, in that order
>> of precedence. Note, however, that the base URI of the contents within
>> the entity-body may be redefined within that entity-body.
>> ================
>>
>> To get the proposal in at the front, I would like to see this
>> changed to require that this header field be used if present:
>
>To confuse matters even further, I interpret the above text as already
>implying that the client MUST use the Content-Base header if present,
>and would maintain that all clients which do not are not compliant
>with the text of the spec.
I agree. The use of Content-Base or an absolute Content-Location
URI to indicate the base is optional, but if sent, the client obviously
must use it (and then possibly override it, if a BASE element is in the
document) to be compliant. The use of Content-Base or an absolute
Content-Location URI in this way has been in the HTTP/1.1 for a very long
time now, and Lynx has it implemented in several releases.
>However, I would not mind if Content-Base is deleted.
>Content-Location can be used to do the same thing anyway.
If there is at lease one other client besides Lynx which has
implemented it, I do not think that it should be deleted. The requirement
is for "two independent implementations" ;( NOT "implementation by two
major commercial clients", though they both should implement it to be
HTTP/1.1 compliant );
Fote
=========================================================================
Foteos Macrides Worcester Foundation for Biomedical Research
MACRIDES@SCI.WFBR.EDU 222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================