Minor clarification, I'm working with the revised text from HTTPbis,
latest draft at all times.
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.
>
> Note specifically, "the current representation", not "a current
> representation", which is why I'm asking. See also my earlier
> clarification.