Re: Content-Location q

On 21 Jan 2011, at 17:32, Nathan wrote:

> 
>   If Content-Location is included in a response message and its value
>   is the same as the effective request URI, then the response payload
>   SHOULD be considered the current representation of that resource.
> 
> Just sanity checking my understanding of the above, that at that instant there is one, and only one, resource representation associated with the resource identified by the effective request URI. Not in some strange philosophical sense, but in the sense that no form of negotiation could have resulted in any other resource representation being sent by the origin server (for instance no possibility that negotiation over the accept header could have provided a different representation).

I don't think your interpretation is correct.

2616 states:
   A server SHOULD provide a Content-Location for the
   variant corresponding to the response entity; especially in the case
   where a resource has multiple entities associated with it, and those
   entities actually have separate locations by which they might be
   individually accessed, the server SHOULD provide a Content-Location
   for the particular variant which is returned.

So (AIUI) the effective request URI will dereference to a resource, but that resource may have multiple entities/representations associated with it. If each of those entities/representations have their own URI then C-L SHOULD contain the entity specific URI, but it's a SHOULD so not all implementations may conform to that behaviour. If the multiple entities/representations share a URI then there is no way for C-L to be entity/representation specific and all bets are off.

So in the general case I would expect the C-L to return the same representation as the effective URI if presented with the same Accept header fields (but I don't think you can guarantee or rely on that). If the Accept header fields differ then all bets are off.

HTH
Ben

Received on Friday, 21 January 2011 18:46:19 UTC