- 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
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." Yes. > The assumption in that statement is that the URI in the > Content-Location header is dereferencable. Yes. > 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 means. 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. Regards Henrik
Received on Friday, 14 May 2010 17:01:10 UTC