- From: Shel Kaphan <sjk@amazon.com>
- Date: Fri, 25 Aug 1995 10:37:14 -0700
- To: John Franks <john@math.nwu.edu>
- Cc: Harald.T.Alvestrand@uninett.no, sjk@amazon.com, bobwyman@medio.com, dmk@allegra.att.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
John Franks writes: ... > What do you propose for the tens of thousands of documents which are > static except for containing a counter? I think a lot of maintainers > are going to want to cache them, but they aren't idempotent GETs. > > John Franks This is a "problem" right now, even without State-Info. If a resource is cacheable, then the counter will not be incremented on each GET, due to cache hits. It is, and will have to remain, in the hands of the server operator how to treat cases like this. The server of a particular resource can use various headers to control cacheability (Date, Last-modified, Expires, Pragma: no-cache, Pragma: private...any others I missed???). If the resource is cacheable, the server operator can't expect to maintain a stateful dialog of any sort using that document (especially if caches don't pass through State-Info or something like it). The idea of idempotence probably needs to be somewhat tempered. It's really only *significant* side effects we have to worry about. If a counter doesn't get incremented, that may (or may not) be deemed significant to the state of a dialog. If a server delivers cacheable documents that contain counters, the cacheability means the server doesn't care that much if the counter is not incremented each time. So, there probably shouldn't be a blanket rule about how all GETs are to be considered idempotent -- that can remain a convention -- but rather, that GETs (and HEADs) *that return cacheable results* are to be considered idempotent. --Shel Kaphan
Received on Friday, 25 August 1995 10:42:39 UTC