Re: MUST use Content-Base

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
=========================================================================

Received on Wednesday, 7 January 1998 10:04:24 UTC