Re: Content-Location q

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.

Received on Friday, 21 January 2011 19:53:19 UTC