RE: GET, POST, and side-effects

Paul Leach writes:
 > Just a simple example of a different kind of cachable POST, which 
 > generalizes to more practical ones.
 > 
 > Suppose I want to provide a "sine()" service -- you tell me an angle in 
 > degrees, and I tell you the sine of that angle.  I could implement this 
 > so that a POST to http://www.sine.com of an entity containing (e.g.) 
 > "x=0" would return an entity containing "y=0". It would be perfectly 
 > OK, for the sine service, to cache this result, and reply to the next 
 > POST to http://www.sine.com of the entity "x=0" with the "y=0" entity.
 > 
 > This property holds true even if sin(x) is generated dynamically every 
 > time, as opposed to being looked up. Sine is a function that is 
 > "reducible" (this term is from the IBM PL/I optimizing compiler): if 
 > you invoke it with the same arguments, it gives the same results.
 > 

This isn't the property that matters here.  If in addition to
returning the sine, that same angle of apple pie were ordered for you
in response to each POST, then it would be important for the POST
request to make it all the way to the origin server each time.  The
property that matters here is whether a POST (or any method) is
capable of generating side effects at the origin server.  Right now
this is hard-wired into the method definitions -- we assume GET and
HEAD have no side effects, and everything else does.  Therefore GET
and HEAD can be answered by a cache, but nothing else can.  This can
be generalized as I described earlier.

 > In order for a proxy to take advantage of this, it needs some 
 > indication that its OK to cache the result. Expires: and Cache-Control 
 > aren't quite enough -- they would say that the URI returned in the  
 > Location: header could be used to as a cache key for the returned 
 > entity value, but not obviously that the same query would return the 
 > same result.
 > 

Expires and Cache-Control on responses only describe the cachability
("freshness period") of the result, not the side-effectfulness of the
request.  These are separable.  (As an aside, Location in and of
itself can't be used as a cache key, because of spoofing
possibilities, but we'll discuss that another time).  What is needed
is a way to clearly indicate in a *request* (not in responses) that
the request may be served from a cache, or must go through to the
origin server.  (See my earlier posts).

 > Note, finally, that it is not necessary for the same query to give the 
 > same result _forever_ -- only that it give the same result for as long 
 > as the Expires: and/or Cache-Control: headers say proxies are allowed 
 > to believe it does.
 > 
 > 

--Shel

Received on Thursday, 4 January 1996 22:58:26 UTC