W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

RE: Clarification on use of Content-Location header

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Fri, 14 May 2010 19:00:09 +0200
To: "Houghton,Andrew" <houghtoa@oclc.org>
Cc: Yves Lafon <ylafon@w3.org>, ietf-http-wg@w3.org
Message-Id: <1273856409.10328.62.camel@localhost.localdomain>
fre 2010-05-14 klockan 10:07 -0400 skrev Houghton,Andrew:

> In use case (3) I guess the point I was trying to make was that
> section 14.14 makes a statement that has an implicit assumption:
> "Future requests MAY specify the Content-Location URI as the
> request-URI if the desire is to identify the source of that particular
> entity."


>  The assumption in that statement is that the URI in the
> Content-Location header is dereferencable.


> For example, is a URN scheme URI, an info scheme URI or tag scheme URI
> allowed in a Content-Location header?

I recommend to stay within the HTTP http:// and https:// URI schemes for
best compatibility, preferably within the same server as requested even.
Content-Location is for example used in authoring to let the client know
the proper location where the resource can be authored to avoid that
they try authoring the resource at any of iẗ́'s aliases. The other use
is to provide a notion of a reasonably permanent location of the
resource, useful if the requested URI is an alias which frequently
changes content such as the news article example already mentioned.

Use of other schemes is not forbidden, but using a scheme which can not
be used for accessing the resource is stupid and kind of defeats the
purpose of Content-Location, and some clients may be a bit upset about
being given a Content-Location which can not be accessed by any known

But it at lest still serves part of it's purpose as an object identifier
enabling cache invalidations etc to trigger on Content-Location updates.

Received on Friday, 14 May 2010 17:01:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:53 UTC