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

Re: Comments on draft-v10-03a.

From: Larry Masinter <masinter@parc.xerox.com>
Date: Wed, 30 Aug 1995 11:11:54 PDT
To: liberte@ncsa.uiuc.edu
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <95Aug30.111202pdt.2763@golden.parc.xerox.com>
Let me try to guess at some of the operational motivation behind the
concept we're trying to define for GET vs POST.

Right now, there are browsers around with a 'reload' button. If you
'reload' something that you obtained using 'GET', then you might get
different results, but it is 'safe' to press reload.  However, if you
'reload' something that you obtained using 'POST', then you might not
want to blindly resubmit the same form data. Many browsers either
complain or ask 'Resubmit FORM data?' when asked to 'reload' something
obtained using 'POST'.

Translating back from this usage scenario to a set of operational
requirements leads me to thinking that we want 'GET' to have no
additional side effects if repeated.

This is only vaguely related to the notion of idempotency. If you
define:

    server-state-after-GET = f<state> ( server-state-before-GET ) 

and ask that f<state> be idempotent. Note that the idempotency only
applies to the 'server state' and not to the value returned.

The property 'idempotent' can only apply when functions have a range
that is a subset of their domain.

If you define

        value-returned = f<value> (server-state-before-GET )

you'll note that range of 'value-returned' is a different
datatype/class and is disjoint from the domain of
'server-state-before-GET'.
Received on Wednesday, 30 August 1995 11:14:24 EDT

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