Re: Idempotent

> 
> > Why not use "cacheable" instead of "idempotent"?
> 
> No, that doesn't work - "cacheable" refers to the object, "idempotent" refers 
> to the method. I would rather say that an idempotent method does not change 
> the topology of the Web.
> 
> The reason for using "topology" and not "state" is that in some cases, 
> idempotent requests can change the state of the web - especially if log files 
> are considered as a part of the state of the Web, or for example if a document 
> can be accessed 5 times.
> 
Now we are getting somewhere....my idea was that when you have a term that 
confuses people, we should dropt the term and replace it with the properties 
we want that term to have.
In particular (these are with respect to the http-v10-spec-02; I can't 
cut&paste from the PostScript snapshots):

   The absoluteURI form is only allowed when the request is being made 
   to a proxy server. The proxy is requested to forward the request 
   and return the response. If the request is idempotent and a
>>>>                                          GET or HEAD 
   response is cached, the proxy may return the cached message if it 
   passes any restrictions in the Expires header field. Note that the 
   proxy may forward the request on to another proxy or directly to 
   the origin server specified by the absoluteURI. In order to avoid 
   request loops, a proxy must be able to recognize all of its server 
   names, including any aliases, local variations, and the numeric IP 
   address. An example Request-Line would be:

.......
6.2.3 Redirection 3xx

   This class of status code indicates that further action needs to be 
   taken by the user agent in order to fulfill the request. The action 
   required can sometimes be carried out by the user agent without 
   interaction with the user, but it is strongly recommended that this 
   only take place if the method used in the request is idempotent
>>>> delete "idempotent" and parentheses 
   (GET or HEAD). A user agent should never automatically redirect a 
   request more than 5 times, since such redirections usually indicate 
   an infinite loop.
.......
10.2  Idempotent Methods
>>>> What actions one can expect from methods
   The writers of client software should be aware that the software 
   represents the user in their interactions over the Internet, and 
   should be careful to allow the user to be aware of any actions they 
   may take which may have an unexpected significance to themselves or 
   others.


   In particular, the convention has been established that the GET and 
   HEAD methods should never have the significance of taking an action 
   other than retrieval. These methods should be considered "safe" and 
   should not have side effects. This allows the client software to 
   represent other methods, such as POST, in a special way so that the 
   user is made aware of the fact that an non-idempotent action is 
>>>>>>                          an action that may have side effects
   being requested.


These are the only four examples of the word "idempotent" in the document;
I think we don't need it.

                   Harald A

Received on Monday, 4 September 1995 00:50:27 UTC