W3C home > Mailing lists > Public > www-amaya@w3.org > July to September 2002

Re: URI base resolution and Content-Location

From: Jose Kahan <jose.kahan@w3.org>
Date: Thu, 12 Sep 2002 13:10:34 +0200
To: Yves Lafon <ylafon@w3.org>
Cc: www-amaya@w3.org
Message-ID: <20020912111034.GA1288@inrialpes.fr>


This sounds quite problematic. I understand using Content-Location for
solving Content-Negotiation problems when publishing. However, using it
as a Base URI is akin to making an unexplicit redirection. This
sounds problematic for an editor, and even when following links.

In the case of an editor, which URL should you use then when making
a link? The one given in the Content-Location? If you do so, then you
may break Content-Negotiation (e.g., linking to image.svg intead of
image, if image exists in many formats).

When following links, you would then follow them relative to the
Content-Location. For example, if open a document at www.example.org
that has a content location value of www.w3.org/, then the
next relative URL you'd browse from there would be taken directly from
www.w3.org and that's the URL we would show in the address field, just
like with a redirection. This sounds confusing.

If the server is able to add a Content-Location header that points
elsewhere than where the document actually is, it may be as easy to
make a redirection to the actual location of the document.

Can you give us some specific examples where this may be useful? 



On Wed, Sep 11, 2002 at 03:47:45PM +0200, Yves Lafon wrote:
> According to rfc2616, section 14.14:
> <<<
> The value of Content-Location also defines the base URI for the
> entity.
> >>>
> I tested that with Amaya, and it uses the request URI instead of the one
> given in Content-Location.
> See http://lists.w3.org/Archives/Public/www-qa/2002Sep/0043.html for a
> better description.
> (I can make a server configuration available, if needed).
Received on Thursday, 12 September 2002 07:10:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:26 UTC