Re: Idempotent

> As for (a), could we say that there is an optional property
> (named idempotence, hysteresis or whatever you want) such that any two 
> consecutive request to the server should return an identical result
> *as far as client is concerned*? I could be wrong, but my idea is that 
> we don't care if the server updates a counter or performs whatever it 
> wants, as long as the client cannot notice it.

You might want to spin that out in more detail; (I know I am stating
the obvious, but I have lost track in some of the discussion now, so
I like to do a few steps back rather than add something: )

I.e: That an idem-potent request; defined by 'method, url, http-version, ...' 
returns the same result ( regardless of anything you did not define a moment
ago between the two tick-quotes; specifically including indepenence of
the time/date, host(s) involved, user-name (from basic-auth or whatever) etc...)
every *time/date* it is issued by the *same* client.

Because what worries me is that we really ought to specify *what* defines
a request. The *whole* header + hosts involved; or just the GET xyz http/get
line with a few accepts... i.e. where to draw the line. 

If you just look at the request; as you should not look at the server itself
then you have
	
	> temporal qualities, i.e. time of RQ and Answer
	> client-host, server-host, port
	> METHOD /ur HTTP/version
	> Misc

I.e. the N-Dimensional approach much talked about :-)

The temporal qualities are the first issue; they are gouverned by expire or
whatever other specific temporal cache information.

The server-host+port is not the issue; they are gouverned by DNS and are at the
discretion of the owner of the server

The client-hist *is* an issue. And should have an explicit cache directive,
ie. Reply-Not-Client-Specific * or Not-Client-Specific *.jrc.it or whatever.

Then you need one for the METHOD, i.e. which ones are OK to cache and which
ones are not,

And so on... for each of the other aspects. Is this notion correct, is this what
we are talking about or have a few aspects already be ruled out ?

Dw.

Received on Thursday, 31 August 1995 02:06:29 UTC