W3C home > Mailing lists > Public > www-talk@w3.org > July to August 1995

Re: Non-persistent Cookie proposal

From: Roy Fielding <fielding@beach.w3.org>
Date: Fri, 11 Aug 1995 17:34:21 -0400
Message-Id: <199508112134.RAA17786@beach.w3.org>
To: koen@win.tue.nl (Koen Holtman)
Cc: dmk@allegra.att.com, www-talk@www10.w3.org
This is a philosophical statement, not a standards one, so there's
no sense in CCing the HTTP-WG.

Herein demonstrates a critical failure in systems philosophy -- trying
to make a client-server system act like a centralized mainframe application.

>These caching problems are in the area of graceful degradation when
>stateful dialogs (for which Session-ID is a support mechanism) are
>used with caches that do not conform to the Expires header definition
>in the (draft) http spec.  Some people, particularly people who want
>to use stateful dialogs in applications where real money is involved,
>are very concerned about such non-conforming caches: the fear is that
>customers will blame them if the service does something inappropriate
>because of a broken cache, while it is really the fault of the cache
>administrator.

It is not just the fault of the cache administrator.  Caching exists
out of necessity, not convenience, and there are too many sites on the net
that disable caching for frivolous reasons (hit counters, poorly
implemented server-side includes, click-trail overanalysis, etc.).
Cache administrators will have two choices: cache responses in spite
of server directives, or deny access to non-cacheable sites.

Cache algorithms will improve when site administrators stop acting
like a bunch of selfish twits!

Systems implementors need to design WWW client-server interaction
appropriately, such that cache-friendly applications can be deployed
just as easily as cache-unfriendly applications.  Like the prisoner's
dilemma, none of these stateful dialogs will be safe until both sides
of the connection return to a sense of communal responsibility.

For example, the Cookie mechanism indiscriminantly defeats caching
by changing the request profile in an opaque fashion.  Cache managers
cannot determine how it has been changed, or why, or even if the
response is cachable in spite of the cookie.  The result is that the
cookie-based transaction will be cached because it is too expensive
not to cache it.

In contrast, the same functionality can be achieved without defeating
caching by separating the 1% of stateful information from the 99% of
cacheable information, thus removing the need for cache managers to
ignore server desires.  It is no harder to implement this than it is
to implement cookies, and the result is a far more reliable service.


 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                      Visiting Scholar, MIT/LCS + World-Wide Web Consortium
                      (fielding@w3.org)                (fielding@ics.uci.edu)
Received on Friday, 11 August 1995 17:37:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:18 GMT