- From: Mike Kelly <mike@mykanjo.co.uk>
- Date: Sun, 7 Nov 2010 16:33:54 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: nathan@webr3.org, HTTP Working Group <ietf-http-wg@w3.org>
On Sun, Nov 7, 2010 at 4:05 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 06.11.2010 04:40, Nathan wrote: >> >> 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. >> > > (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
Received on Sunday, 7 November 2010 16:34:30 UTC