Re: Clarification on use of Content-Location header

On Thu, 13 May 2010, Houghton,Andrew wrote:

> 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.

CL is not linked to conneg, for example see this:

GET /news/latest HTTP/1.1
Host: www.example.com
[..]

HTTP/1.1 200 OK
Content-Type: text/html
Content-Location: /news/newsitem-20100514.html

This is not conneg, and CL is giving useful extra information.

> 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.

The fact that the request has Accept* headers does not imply that conneg 
is used to generate the response, the only indication that conneg occured 
is the presence of the Vary: header in the response.

> 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.

What do you mean by proxy here? The scenario looks more like an aggregator 
or a gateway, rather than an HTTP proxy.

> 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.

If it is useful, then sure the server can always point to a specific URI 
in CL, it is a server choice anyway.

> 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.
>

Also take a look at the definition of Content-Location at:
http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-09#section-5.7


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

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Thursday, 13 May 2010 22:24:42 UTC