Clarification on use of Content-Location header

The purpose of this message is twofold: 1) get feedback from the WG and others, and 2) raise the issue for possible wording changes to RFC 2616, section 14.14 Content-Location.

The issue in question is the wording in RFC 2616, section 14.14 Content-Location. Some people in our organization interpret this section to mean: "the Content-Location header signifies that content negotiation has taken place and the user agent will expect that the provided URI will always get them to the resource returned in the entity of the message." Other people in our organization interpret this section in a broader context: "the Content-Location header establishes a relationship between the requested URI and a URI of the resource returned in the entity of the message." As you probably have guessed this debate is having a paralyzing affect on our projects.

The former camp (FC) believes that the Content-Location header can *only* be used in the context of content negotiation.  The latter camp (LC) believes that the Content-Location header can be used for other use case scenarios besides content negotiation.  The issue of whether or not the Content-Location header is exclusively used for content negotiation has to do with the second sentence in section 14.14.

From my perspective, after reading section 14.14, it seems to me that the first sentence gives the scope of the header which does not appear to be limited to content negotiation.  The second sentence seems to me to give a specific use case where it is recommended that an implementer provide a Content-Location header.  Consider the following use cases:

1) A GET is done on a resource URI with one or more Accept* headers. The server responds and includes a Content-Location header corresponding to the resource returned in the entity of the message.

2) A GET is done on a resource URI with no Accept* headers. The server is a proxy which retrieves the resource from a remote location. The server responds with the entity containing the remote resource and a Content-Location header containing the URI of the remote resource.

3) A GET is done on a resource URI with no Accept* headers. The server accesses a backend data store whose resources are identified with either HTTP scheme URIs or URN scheme URIs. The server returns the resource from the data store and a Content-Location header containing the URI used by the data store to identify the resource under its management.

4) A GET is done on a resource URI with no Accept* headers. The resource URI is a variant representation of a generic resource. This scenario is described in the W3C TAG Finding 1 November 2006 [1], see [2] for a diagram of the scenario. For argument sake lets choose the bubble "MobileEnglish" as the resource URI that the GET was done on.  The server responds with a Content-Location header to the URI for the bubble "GenericGeneric". The TAG Finding describes this in the context of HTML linking which is only specific to its media type however, this can be accomplished (the LC interpretation) at the HTTP protocol level by using the Content-Location header to provide a media type agnostic mechanism. This use case, mapped to the HTTP protocol, is described in section 4 bullet 2 of the TAG finding: "given one of the alternatives for a resource, ensure that one can reach the corresponding generic resource by traversing a contained hyperlink". Use case (1) above, mapped to the HTTP protocol, is described in section 4 bullet 2 of the TAG finding: "When creating a generic resource with multiple alternatives, encode hyperlinks to the available alternatives with the generic resource".

Both camps agree that use case (1) should include a Content-Location header in the response.  What about use cases (2-4)?  Do those use cases fall within the letter and spirit of RFC 2616? Thanks in advance for helping clarify this issue.


Andy.

[1] <http://www.w3.org/2001/tag/doc/alternatives-discovery.html>
[2] <http://www.w3.org/2001/tag/doc/alternatives-discovery.html#id2269389>

Received on Thursday, 13 May 2010 17:41:47 UTC