W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

Re: Content-Location q

From: Nathan <nathan@webr3.org>
Date: Fri, 21 Jan 2011 19:47:59 +0000
Message-ID: <4D39E2EF.9030007@webr3.org>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
CC: HTTP Working Group <ietf-http-wg@w3.org>
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:49:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:56 UTC