Re: Content-Location q

Nathan,

On 21 Jan 2011, at 19:47, Nathan wrote:

> Ben Niven-Jenkins wrote:
>> 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.
> 
> It appears to me that you're discussing the case where the C-L differs from the effective request URI, or no C-L is given, whereas I'm specifically asking about the case when the C-L is the same as the effective request URI.
> 

I'm also talking about the case when the C-L is the same as the effective request URI. Let me try again:

The sentence directly after the one you quote at the top of this email states:
   For a GET or HEAD request, this is the same as the default semantics
   when no Content-Location is provided by the server.

Furthermore, section 6.1 of p3 (Identifying the Resource Associated with a Representation) states:
   3.  If the response has a Content-Location header field, and that URI
       is the same as the effective request URI, the response payload is
       a representation of the target resource.

So IMO, the C-L makes no guarantee over the representation that will be returned when dereferencing the URI in the C-L.

> Note specifically, "the current representation", not "a current representation", which is why I'm asking. See also my earlier clarification.

I do not think "the current representation" is meaningful to a server if it has more than one representation for a given resource. 

Ben

Received on Friday, 21 January 2011 20:16:19 UTC