Subject: Identifying the Resource Associated with a Representation?

From: Nathan <[email-masked]>
Date: Sat, 06 Nov 2010 03:40:21 +0000

Hi,

 From an HTTP response I need to be able to work out an identifier for a 
resource, from the Content-Location, in order to:

(a) which URI to send PUT and DELETE requests to
(b) which URI to store a cached representation against.

And also:

(c) which URI to use as @base (say it was a text/html response)
(d) which URI to use on the next GET for the same resource

Please do assume that Content-Location is different from the effective 
request URI for my use-case(s) above.

I'd initially thought this was as simple as look at the Content-Location 
header and use the value.

However, first if it's a relative-part then to what base is it resolved 
against? the target resource (effective request URI)? assuming this is 
correct.

Then I hit p2-semantics section 6.1 - "Identifying the Resource 
Associated with a Representation" [1] - and got a bit more confused. 
Here's a relevantly snipped version of the text:

    ... To determine the URI of the resource a response is
    associated with, the following rules are used (with the first
    applicable one being selected):

    1.  If the response status code is 200 or 203 and the request method
        was GET, the response payload is a representation of the target
        resource.

    2.  If the response status code is 204, 206, or 304 ...

    3.  If the response has a Content-Location header field, and that URI
        is the same as the effective request URI ...

    4.  If the response has a Content-Location header field, and that URI
        is not the same as the effective request URI ...

How can I ever get to step 3 or 4 to figure out the identifier I should 
be using for my use-cases above?

Problem: "(with the first applicable one being selected)" - the first 
applicable being 1... "is a representation of the target resource"

Thanks for any clarification,

Nathan

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#page-14

---

From: Julian Reschke <[email-masked]>
Date: Sun, 07 Nov 2010 17:05:16 +0100

On 06.11.2010 04:40, Nathan wrote:
> ...

I believe the answer is: this section doesn't help you for all these 
questions.

(a) You can use the one determined by these rules, but C-L may provide a 
more specific one.

(b) Not entirely sure what you mean here.

(c) We have removed the base-setting semantics from C-L 
(<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154>), so it's the 
URI as determined by the rules in 6.1.

(d) The same URI in general (do we imply otherwise somewhere)?

Best regards, Julian

---

From: Mike Kelly <[email-masked]>
Date: Sun, 7 Nov 2010 16:33:54 +0000

> (b) Not entirely sure what you mean here.

I think I do; and as it stands the spec says:

http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-12#section-6.7

"A cache cannot assume that a representation with a Content-Location
   different from the URI used to retrieve it can be used to respond to
   later requests on that Content-Location URI."

Which implies that any cache controls apply only to the effective
Request URI. Understandable, because the conditions for variance could
differ between the URIs.

Initially I felt this was bit odd given this bit on 'Request Methods
that Invalidate':

http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-12#section-2.5

The following HTTP methods MUST cause a cache to invalidate the
   effective Request URI (Section 4.3 of [Part1]) as well as the URI(s)
   in the Location and Content-Location header fields (if present)

but on reflection this does actually make sense since invalidation is
about general resource state, whereas cache controls and vary are
representation specific. It would also require a statement only
allowing same-origin URIs to ensure the mechanism was secure.

Out of interest; has anyone explored the possibility of a specific
cache-control directive that could indicate that the cache conditions
apply to the Content-Location URI?

 Cheers,
Mike

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 Nov 2010 12:22:30 +1100

> apply to the Content-Location URI?

The problem is one of trust; if you own http://example.com/~mike/a and I own http://example.com/~mark/b, you don't want my responses making asserting things about yours.

What's interesting is that there's talk in a few different places (mostly security communities, e.g., WEBSEC and the W3C) about policy frameworks; this may provide something to hang these sorts of semantics off of as well.

Cheers,

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

---

From: Mike Kelly <[email-masked]>
Date: Tue, 9 Nov 2010 11:18:27 +0000

Ok - how does that leave the cache invalidation rule for C-L and
Location? Do the same concerns over trust not apply?

Cheers,
Mike

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 Nov 2010 22:38:25 +1100

It's a matter of degrees; the worst that can happen with invalidation is that there will be a cache miss. If a cache were to use C-L to satisfy future requests at that URL, it would allow cache poisoning.

Cheers,

---

From: Mike Kelly <[email-masked]>
Date: Tue, 9 Nov 2010 12:48:07 +0000

Ok, thanks for clarifying.

Regardless - it does sound here as though a 200 with C-L response to a
GET should be considered to have rule 4 applied. Correct?

Cheers,
Mike

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Nov 2010 10:06:38 +1100

Yes, but really you're just looking for a definition of Content-Location; see
  http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-12#section-6.7

Cheers,