Subject: Content-Location q

From: Nathan <[email-masked]>
Date: Fri, 21 Jan 2011 17:32:19 +0000

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).

Best,

Nathan

---

From: Nathan <[email-masked]>
Date: Fri, 21 Jan 2011 17:51:01 +0000

> accept header could have provided a different representation).

I'm trying to determine whether the following is true or not:

When a server responds with a 20O OK to a GET, then at that instant, the 
resource identified by the effective request URI is associated with a 
set, and each member of that set is a representation, and each 
representation may optionally be associated with an identifier.

If the representation returned is associated with an identifier (given 
by the Content-Location header) and that identifier is the same as the 
effective request URI, then the set (at that instant) consists of one, 
and only one, representation.

If the identifier in the CL is different, then you know the set consists 
of at least one member (not exactly one, rather one or more).

TIa,

Nathan

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 21 Jan 2011 18:45:48 +0000

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

> 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

---

From: Nathan <[email-masked]>
Date: Fri, 21 Jan 2011 19:47:59 +0000

> 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…

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.

Cheers,

Nathan

---

From: Nathan <[email-masked]>
Date: Fri, 21 Jan 2011 19:51:06 +0000

Minor clarification, I'm working with the revised text from HTTPbis, 
latest draft at all times.

Nathan wrote:
>>> 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).
>>
>> 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.
>

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Fri, 21 Jan 2011 20:15:36 +0000

Nathan,

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

> 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

---

From: "Eric J. Bowman" <[email-masked]>
Date: Fri, 21 Jan 2011 13:22:32 -0700

Nathan wrote:
> 
> If the representation returned is associated with an identifier
> (given by the Content-Location header) and that identifier is the
> same as the effective request URI, then the set (at that instant)
> consists of one, and only one, representation.
> 

No, because of compression, or authentication.

-Eric

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 26 Jan 2011 12:55:22 +1100

I think it should be 'a current representation' -- i.e. that it shouldn't be read to constrain cardinality.

Anyone else?

--
Mark Nottingham   http://www.mnot.net/

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 26 Jan 2011 10:45:24 +0000

> I think it should be 'a current representation' -- i.e. that it shouldn't be read to constrain cardinality.

Makes sense to me and it would align the wording with section 6.1 of p3.

Ben