- From: Paul Leach <paulle@microsoft.com>
- Date: Thu, 31 Aug 95 19:44:09 PDT
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Applying the mathematical concept of idempotence to HTTP, idempotent means that two consecutive (as seen at the server) requests with the same method and the same URI will return results that are functionally the same, as far as the client and server are concerned (this allows minor, irrelevant changes like counters, etc.). It is the fact that requests are idempotent that *allows* them to be cached: the cache can service the second request out of its cache if-and-only-if it knows that the request is idempotent. In HTTP, a cache knows that (i.e., is allowed to act as if) the request is idempotent if the response that was cached had an Expires header with an expiration date in the future. Not all GETs and HEADs are idempotent. If they return an Expires header for some URI, then clients and caches should be allowed to assume that they are for that URI, until the expiration date (and correct servers will cause it to be true). In addition, idempotent requests may safely be retried if they time out. Some non-idempotent requests are also safe to retry, but not all. This is consistent with the mathematical usage of the term "idempotent", and its use in communications protocols like RPC. It is also fundamental to the principles of caching. I propose the following addition to section 1.3: idempotent A request is idempotent if two consecutive identical requests (same method, same URI) received at a server will return responses that are functionally the same, as far as the client and server are concerned. Paul
Received on Thursday, 31 August 1995 19:46:40 UTC