RE: questions -- clarifications requested

Paul Leach writes:
 > 
 > Shel writes:
 > ]
 > ] More ruminations.
 > ]
 > ] Paul Leach writes:
 > ]  > 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,
 > ]
 > ] What does that mean?  By definition what is returned as the result of
 > ] an action is the result of the action.
 > 
 > I didn't write it!

The part I questioned is the part you wrote.  The spec is quite
general, but it doesn't have to be more specific.  The usage is that
when any of these methods are send by a user agent, the user agent is
then going to have to display some page -- a page that is returned by
the server.  In order to make it possible to storyboard interactive
services in a general way, it has to be possible to have the
returned resource be whatever the server wants to send in response to
the request.

 Here's what I thought it was saying:  there could be 
 > two flavors of POSTs; an example of each might be:
 > Flavor 1:
 > The entity-body in the request says "order 17 gross of 3 penny nails"; 
 > and the the entity-body in the response says: "your order has been accepted".
 > Flavor 2:
 > The entity-body in the request says: "fetch me item 33" and the 
 > entity-body in the response is item 33.
 > 
 > The first is an example of the entity-body describing the result of the 
 > action; the second is one containing the result of the action.
 > 
 > In flavor 2, one could expect to do a GET on the URL in the Location 
 > header field in the response, and get item 33 again. For flavor 1, 
 > although it conflicts with your observation below, it doesn't seem to 
 > me to make sense that there _must_ exist a URL to put in the Location 
 > header such that a GET on it would return an entity containing "your 
 > order has been accepted" again.  Nor does it seem very useful to cache 
 > either "order 17 gross..." or "your order has been accepted".  Is that 
 > really the intent?
 > 

No, the intent is that if the POST returns something that it would
make sense for a GET to get from a cache later, that it should be
possible.  If this is desired, the server should (a) either give the
response a URI with Location that later GETs will correspond to, or
(b) arrange for future GETs to use the same request-URI as the POST
did, and (c) arrange for the document to be cacheable by proper use of
Expires, Last-modified, etc.  It need not be the case that all returns
from POST be cached and that links be provided to fetch it from the
cache, it only needs to be *possible* so that people who need this
functionality can have it.

--Shel

Received on Wednesday, 30 August 1995 10:34:56 UTC