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/

Received on Monday, 5 January 1998 09:58:56 UTC