RE: MUST use Content-Base
Yaron Goland (yarong@microsoft.com)
Tue, 6 Jan 1998 22:26:04 -0800
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/