RE: GET, POST, and side-effects

Paul Leach writes:
	...
 > In which case, it isn't a "sine server" at all, but a 
 > "sine-and-apple-pie" server, and the sine-and-apple-pie function is 
 > _not_ reducible.  I think I used "result" in an ambiguous way in my 
 > original post -- I meant it in the sense of the total effect of the 
 > function, not the narrower sense of the resulting entity.
 > 
 > I agree that the POSTs to the sine-and-apple-pie server need to make it 
 > 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.
 > 
 > We agree 100% on this.
 > 

OK, so the problem at hand, then, is how to represent the information
that a POST to the sine server has no side effects, whereas a POST
to the sine-and-apple-pie-server does have side effects.
(I always wanted to specify my pie servings in radians...)

I am certainly open to alternative representations of this.

 > 
 >   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).
 > 
 > This I disagree about.  It seems clear to me that only the server knows 
 > whether the POST will have side effects, and that identical requests 
 > return identical results. It seems easy enough to have the server 
 > indicate that on the response to a POST, and I don't see how the client 
 > could know.
 > 
 > Paul
 > 

Ultimately, I agree that the server knows best.  If you can come up
with a better idea than mine for how to control this I'm all ears.

Some additional header in responses that told caches how to deal with
subsequent requests might work ... we'd have to work out the details.


(...late breaking synaptic activity:...)
I just got an idea that might be simpler than trying to control this
using headers, and doesn't require convincing any HTML people of
anything.  Just invent some new methods that implement
side-effect-free versions of POST, etc.
Then we can define the cache actions differently based on
the method.

Later, when we talk about caching vs. extension methods, we'll have to
talk about how to control this for methods not yet known to a cache.


--Shel

Received on Friday, 5 January 1996 01:37:56 UTC