Subject: Clarification on use of Content-Location header

From: "Houghton,Andrew" <[email-masked]>
Date: Thu, 13 May 2010 13:41:03 -0400

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>

---

From: Yves Lafon <[email-masked]>
Date: Thu, 13 May 2010 18:24:39 -0400 (EDT)

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

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

         ~~Yves

---

From: "Houghton,Andrew" <[email-masked]>
Date: Fri, 14 May 2010 10:07:41 -0400

A few clarifications.

In use case (2) I was using the word "proxy" loosely in the sense of gateway rather than an HTTP proxy, sorry for the confusion.

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?  If so, then a user agent cannot make future requests since those URI schemes cannot be dereferenced. Perhaps additional clarification and guidance could be added to the standard.

Thanks for the information, Andy.

> -----Original Message-----
> From: Yves Lafon [mailto:[email-masked]]
> Sent: Thursday, May 13, 2010 06:25 PM
> To: Houghton,Andrew
> Cc: [email-masked]
> Subject: Re: Clarification on use of Content-Location header
>

---

From: Henrik Nordström <[email-masked]>
Date: Fri, 14 May 2010 19:00:09 +0200

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 iẗ́'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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 14 May 2010 12:36:15 -0700

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

All schemes are dereferenceable, including urn, info, and tag.
Specific resources might not be (just like for http).

....Roy

---

From: Henrik Nordström <[email-masked]>
Date: Fri, 14 May 2010 22:09:18 +0200

> All schemes are dereferenceable, including urn, info, and tag.

Are they?

Quote from the tag scheme specification RFC4151:

        There is no authoritative resolution mechanism for tags.  Unlike
        most other URIs, tags can only be used as identifiers, and are
        not designed to support resolution.  If authoritative resolution
        is a desired feature, a different URI scheme should be used.

Some of the  URN name spaces have similar issues.

Also still have not quite understood what makes tag differ from an urn
name space but that's not an httpbis topic. I guess the difference is in
namespace resolution where URN namespaces generally need to be defined
and have a meaning but tag is just abstract identifiers with no
requirement on any defined meaning.

Also the messiness of tag etc does not change the general rule with
respect to use of other schemes in HTTP Content-Location, just makes tag
a bit impractical to be used in Content-Location.

Regards
Henrik

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 14 May 2010 14:34:32 -0700

>> All schemes are dereferenceable, including urn, info, and tag.

Yes.  Any scheme can be proxied through HTTP, even when it
might be unwise to do so.

> Some of the  URN name spaces have similar issues.

That doesn't prevent anyone from introducing a resolution, deploying
it, and then configuring their web tools to dereference it.

There is a long history of URN-like specifications living in some
fantasy land that has no correspondence with Web technology.

....Roy