W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: Possible optimization to State-Info proposal

From: Shel Kaphan <sjk@amazon.com>
Date: Fri, 25 Aug 1995 10:37:14 -0700
Message-Id: <199508251737.KAA23439@bert.amazon.com>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:26 EDT