Re: Possible optimization to State-Info proposal

On Mon, 28 Aug 1995, Dave Kristol wrote:

> koen@win.tue.nl (Koen Holtman) wrote:
> 
>   > >From this, I read that:
>   >  - GET and HEAD are defined to be the idempotent methods
>   >  - idempotent means `safe'.
> 
> Sorry to be a pain, but what do you mean by "safe"?  This is the
> philosophical vs. operational divide.  The definition so far has been
> operational:  GET and HEAD are idempotent; they have no side-effects.
> Okay.  But what are we implying when we say that?  What is the
> philosophical definition, in the context of WWW?

The discussion I have read not too many weeks back was that idempotent
meant that the transaction made no changes at the server which would
cause a subsequent re-issue of the same transaction to cause anykind
of failure.  For this paragraph/context a transaction would be a 
method and URL. This definition does not preclude the possiblity
that a GET/URL will provide a different response EACH time because
of other activities at the server.  The obvious example is the
search of a dynamic data base.  

Because each use of the GET/URL may be different, it is important
(in my very strong opinion) from a user interface perspective that
the User Agents be permitted to maintain mechanisms (like the
history list we often see) which provide a stable view of the
result the user expects to reference multiple times as they digest
the document, follow links and return.  There are two distinct
possible facilities a User Agent could provide .. the relatively short
instance of the user agent program session history list and a cache.

The session history is like an XTERM scroll buffer and logically
belongs to the user.  The cache is an extension of the server(s) and
is designed to optimize perormance.  The cache should respond to and
be managed by caching control headers.  If the history changes at
all as a result of server actions, the controls need to be disjoint
form caching controls ... for example, dynamic documents resulting
from approach such as client-pull/server-push support.

It is clear from this protracted discussion that overloading the
meaning of headers leads to much confusion. Use cache headers to
control document caching and state-info headers for state info.

I believe I have seen concensus that a cache should not deliver
state info.  Therefore it behooves the application which requires
state-info to suppress caching itself when the loss of state
info because of an intervening cache would cause a problem.

Finally, if a cache circumvents the protocol for its own tuning
it is a broken cache. A program bug could have the same effect. Thus,
I believe the protocol we specify should attempt be robust in the face of
all manner of bugs and breakage and in particular prevent incorrect
result. Attempting to accomadate broken caches should not be our
concern (but on the other hand we should try and avoid introducing
network behaviors with new protocols which increase the incentive
for cache administrators to breake the protocols).

Dave Morris

Received on Monday, 28 August 1995 23:58:58 UTC