Re: cache keys

David W. Morris writes:

	...

 > Well the complexity here, including the spoofing issues (which I can
 > relate to but don't completely understand yet) has in part to do with
 > tion of what the URI identifies.  The response to "PUT XXXX"
 > surely has little correlation to the response to "GET XXXX".

(Peeling away the layers of assumptions I've made): Sure, you're
right.  There are two things we could say here, and maybe both are
true.  

- If a PUT is successful, then we know (don't we?) that the
request-entity-body must be the new version of the object, and (modulo
freshness considerations and content negotiation) could be returned on
future GETs on that URI.

- If a PUT is successful, and the response contains a Location header,
what does it mean?  There seem to be multiple possible interpretations, with
different levels of usefulness.  At least this much is presumably true: 
The server stored the request-entity-body, and its new URI is the location-URI.
If there's a location-URI and it's a 200 response, does that mean
that the response also contains the entity named?  Or might it also be a
"you succeeded" message?

The fundamental issue here is whether doing a PUT through a cache can
*somehow* affect a later GET on the same URI through the same cache.

 > 
 > I wonder if _anybody_ would get _it_ right where 'it' is any part of the
 > protocol which gets too complicated. We gotta keep testing against this
 > standard.
 > 
 > Dave Morris

I agree completely, however I think our intermediate versions and
thought experiments can be allowed to be complicated so that we
can see all the weird cases.  At the end, though, if simple things
aren't simple to do, and if the whole thing doesn't seem to have some
logical cohesiveness, we'll have failed.

--Shel

Received on Monday, 8 January 1996 20:09:42 UTC