RE: questions -- clarifications requested

Paul Leach writes:
 > 
 > ----------
 > ] From: Shel Kaphan  <sjk@amazon.com>
 > ] To: Paul Leach
 > ] Subject: questions -- clarifications requested
 > ] Date: Tuesday, August 29, 1995 10:25AM
 > ]
 > ] Paul Leach writes:
 > ] 	...
 > ]  >
 > ]  > 9. Is the Expires entity-header field ever returned from POST, PUT,
 > ]  > DELETE, LINK or UNLINK methods? (These are never cached, and the
 > ]  > description implies of Expires implies it is only used for caching 
 > purposes.)
 > ]  >
 > ] 	...
 > ]
 > ] The *results* of these operations can be cached.  The expires header
 > ] is appropriate.  Requests for these methods must go all the way
 > ] through to the origin server, and cannot be served from a cache
 > ] themselves.  The results can be identified with the Location header in
 > ] such a way that a subsequent GET or HEAD can retrieve *its* results
 > ] from the cached resource left in the cache by the POST, PUT, etc.
 > 
 > This wasn't the answer I was expecting, so let me explain why I asked 
 > the question.
 > 
 > This answer seems inconsistent with the description of the nature of 
 > the entity-bodies returned from PUT, DELETE, LINK, UNLINK:
 > 
 > (Sec. 6.2.2) "an entity describing the result of the action"
 > 
 > >From this I concluded that it *isn't* the content associated with the 
			       ^^ what is "it"?
 > URI, so that a subsequent GET shouldn't return the _entity_ returned 
 > from these methods. The entity-headers are associated with the resource 
 > named by the URI, so they could be cached (or the entity-headers 
		^^^ Which one?
 > associated with an already cached copy updated). This won't do much 
 > good if the entity itself isn't cached, though, as the next GET will 
 > still miss and force a trip to the origin server.
 > 

I'm not sure I understand this paragraph, but I'll interpolate.
*Which* URI? do you mean?  The request-URI, or the one named in the
response (with Location)?  I claim it makes much more sense for it to
be the latter.

I'm really not sure I'm with you.  I think you need to decouple the
entity returned from the request method/URI.  If a server returns a
resource in response to any method request, that returned resource, if
identified by a Location header, should *clearly* be cached (if it is
cacheable according to other headers) using the Location response
header as its key.  This enables, for instance, "shopping basket"
applications where a POST (with URI `A') can change the contents of the
basket and display the results, and then subsequent GETs (with URI `B')
can fetch the *cached* results.   Right now, without the Location
header in force, this is hard, and what is worse, if the shopping
basket contents are returned in response to different POSTs, GETs (and
possibly other methods), you end up with multiple *different* cached
copies of the same resource, some stale.  I have been trying to make
this point for a long time, and I am not sure the importance of it has
sunk in yet.  I can promise you, if you tried to implement a
usable dynamic web service, you would soon understand why this is an
important issue.  This is one of the most important things the Location
header buys.

I'm not going to comment on all the other specific methods you
mentioned, as they are not much in use now -- I really just want to
concentrate on POST, since that and GET are the two most important
methods right now.

 > For POST, the situation is more complex, since it says that the entity 
 > returned is
 > 	"an entity describing or containing the result of the action"
 > If there were a way to determine that it contained the result of the 
 > action, and some guarantee that a subsequent GET (of the URI specified 
 > by the Location header in the response) would fetch this entity, then 
 > your argument would hold. However, since neither of the predicates are 
 > true, it seems that the conclusion doesn't follow.
 > 

POST is the clearest case where this functionality is helpful.
(See the shopping basket example above).

 > So, that's why I posited that Expires shouldn't be returned from POST, 
 > PUT, DELETE, LINK, and UNLINK.
 > 
 > And, having thought about it to respond to Shel, I also conclude that 
 > POST, PUT, and DELETE should be specified to delete any cached copies 
 > (if successful), and that the results from all these methods should 
 > *not* be cached.
 > 
 > Paul
 > 
 > 

Sorry, but to the extent I follow your argument, I could not disagree
with you more.  My thoughts about this are driven by practical
examples where I've had to do things I don't want to describe here to
simulate this functionality.  I've been looking forward to the day
when HTTP supports such things naturally, and I certainly hope
the HTTP-WG will not throw away this new functionality.  Indeed, I
sincerely hope it will be more fully written into the spec!

--Shel Kaphan

Received on Tuesday, 29 August 1995 18:18:08 UTC