RE: MUST use Content-Base

FWIW, this is clearly an editorial mistake....

Here is the current wording:

>     If no Content-Base field is present, the base URI of an entity is
>     defined either by its Content-Location (if that Content-Location URIs is
>     an absolute URI) or the URI used to initiate the request, in that
>     order of precedence.

It is unambiguous as written, but does not conform to Bradner MUST, MAY, 
SHOULD terminology.  If I were implementing this spec, I think I'd get it 
right, as is (though the wording clearly should conform to Bradner
terminology).  Fixing it to conform with Bradner terminology would of course
remove any doubt in implementer's minds.

You can't just remove it from the spec, as datatypes other than HTML/XML
have no way to specify a base URL for the entity.  The functionality is
in fact really needed.

To make draft standard, we do have to show two running implementations,
of course.

As to formal conformance, saying you conform to a proposed standard
is nice, but doesn't mean much, as proposed standard by definition admits
to the possiblity of errors in the specification.

				- Jim



From: Yaron Goland <yarong@microsoft.com>
Date: Tue, 6 Jan 1998 22:26:04 -0800 
To: "'Scott Lawrence'" <lawrence@agranat.com>,
        HTTP Working Group
	 <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Subject: RE: MUST use Content-Base

Hum... now call me picky but it seems bad pool to make clients who implement
based on an RFC non-compatible when switching from draft to proposed. 

It was a MAY in RFC 2068 and should continue to be a may in the proposed
standard. If this makes the feature useless then pull it out but don't go
around punishing people who implement based on RFCs.

			Yaron

> -----Original Message-----
> From:	Scott Lawrence [SMTP:lawrence@agranat.com]
> Sent:	Monday, January 05, 1998 7:48 AM
> To:	HTTP Working Group
> Subject:	MUST use Content-Base
> 
> 
>   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:
> 
>   ================
>     The Content-Base entity-header field may be used by a server to
>     specify the base URI for resolving relative URLs within the
>     entity.
> 
>            Content-Base      = "Content-Base" ":" absoluteURI
> 
>     If the Content-Base header field is present, clients MUST use its
>     value as the base URI of the response entity unless it is
>     overridden within the entity-body.  If the base is not defined
>     within the entity body and no Content-Base is present, the base
>     URI 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.
>   ================
> 
>   This is consistent with the idea of 'nested' definition of the base
>   URI as described in RFC 1808 "Relative Uniform Resource Locators"
>   (which is already referenced from the HTTP/1.1 spec).
> 
>   This is very useful to the origin server and content author; it
>   provides a mechanism for providing the base value in a number of
>   situations:
> 
>   - When the request URL is not the base for the response
>   ( http://server.co.xx/cgi-bin/search ); in some cases, the
>   response may not have a location that could be retrieved otherwise,
>   so that it may be inappropriate to send a Content-Location.
> 
>   - When the request URL uses extra information in the path (as in the
>   CGI PATH_INFO mechanism):  http://server.co.xx/foobar/param1/param2
>   where http://server.co.xx/foobar is the real entity and param1 and
>   param2 are inputs to it encoded as path components.
> 
>   - When the Content-Location is being used to identify a negotiated
>   variant, but relative links within the entity are the same for all
>   variants ( /foo/en/welcome.html and /foo/fr/welcome.html both
>   contain relative links to /foo/... ).
> 
>   It is true that if the entity returned is HTML then it can include a
>   BASE tag, but this means that the content author must know the
>   absoluteURI where the content is installed, and that information
>   must be either generated dynamically for each request or globally
>   changed when the content is moved (problematic for replicated sites,
>   for example).
> 
>   If we decide not to add the proposed normative requirement, then I
>   suggest that it would be better to strike the Content-Base mechanism
>   from the spec altogether; as it stands now it appears to provide a
>   mechanism for solving a common content-author problem, but it will
>   not work uniformly enough to be actually useful (if the author must
>   do something else to get the base correct for clients that ignore
>   Content-Base, then sending it at all is a waste of bytes).
> 
> --
> Scott Lawrence           EmWeb Embedded Server
> <lawrence@agranat.com>
> Agranat Systems, Inc.        Engineering
> http://www.agranat.com/
--
Jim Gettys
Industry Standards and Consortia
Digital Equipment Corporation
Visting Scientist, World Wide Web Consortium, M.I.T.
http://www.w3.org/People/Gettys/
jg@w3.org, jg@pa.dec.com

Received on Wednesday, 7 January 1998 09:12:24 UTC