W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

RE: MUST use Content-Base

From: Yaron Goland <yarong@microsoft.com>
Date: Tue, 6 Jan 1998 22:26:04 -0800
Message-Id: <3FF8121C9B6DD111812100805F31FC0D0E71FA@red-msg-59.dns.microsoft.com>
To: 'Scott Lawrence' <lawrence@agranat.com>, HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
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/
Received on Tuesday, 6 January 1998 22:28:55 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:09 EDT