RE: Clarification on use of Content-Location header

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:ylafon@w3.org]
> Sent: Thursday, May 13, 2010 06:25 PM
> To: Houghton,Andrew
> Cc: ietf-http-wg@w3.org
> Subject: 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 Friday, 14 May 2010 14:08:39 UTC