Re: Comments on draft-v10-03a.

Daniel LaLiberte writes:
 > Shel Kaphan writes:
 >  > Paul Hoffman writes:
 >  >  > >Idempotent
 >  >  > 
 >  > Can anyone think of a word that means "without significant
 >  > side-effects"?  Maybe there's some good word from functional
 >  > programming languages. I think that is closer to what is needed than
 >  > "idempotent", which always did seem like not quite the right word.
 > 
 > No, side-effects are not the issue at all.  The result returned by the
 > server needs to be the "same" each time to be considered idempotent,

We're talking about whether the concept of idempotence is the right
concept, not whether GET and HEAD satisfy a dictionary definition of "idempotent".
And side effects are exactly the issue.

Larry Masinter said it like this:

	I think we're better off sticking with computer science terminology,
	rather than reaching into mathematics when describing Internet
	protocols. I'd suggest we say that GET should be
	
	  "without additional side-effects if invoked again."

		...	

	Note that this definition says nothing at all about what is returned
	by the GET method, which may return a different result every single
	time, no matter how closely spaced the calls are. The issue is whether
	doing it again has an effect on the state of the server.

 > but each time a result is computed, it can have whatever side effects
 > it wants to.

If that were true, it would be unsafe to ever cache anything.  What we
need is the appropriate definition of whatever-property-it-is that
makes it reasonable and appropriate to cache something.

  It could have no side effects itself and still return
 > very different results each time - obviously, something else is having
 > a side effect in that case.
 > 

So?  If there are no side effects on the server, then unless a cached
copy is outdated, it is legitimate to serve it from the cache.  It is
the side effects that matter, not the difference in the returned
result each time you re-fetch it from the origin server.

 > Actually, "same" can be quite different too, as long as it calls it
 > the "same".

Say what?

  The server decides what it thinks is equivalent to what.
 > If it decides badly, it is a bad service.
 > 
 > Any particular method may or may not be idempotent, in my opinion,
 > whether GET, POST, SEARCH or whatever.  There is no reason to define
 > in the spec that a particular method is always (or never) idempotent.
 > The server simply tells the client whether a particular use of a
 > method is idempotent with the no-cache header, or whatever it is
 > called now.
 > 

There you've got an interesting idea, though I'll have to consider the
ramifications.  Most methods, such as POST, don't really make sense
unless they go all the way through to the origin server.  What would
it mean to serve a POST from a cache? It's not clear if it really
makes any sense.  There would undoubtedbly be some problems with
downwards compatibility too, but I think this is worth thinking
through.

 > Daniel LaLiberte (liberte@ncsa.uiuc.edu)
 > National Center for Supercomputing Applications
 > http://union.ncsa.uiuc.edu/~liberte/

--Shel Kaphan

Received on Wednesday, 30 August 1995 11:48:10 UTC