W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Re: On transparency

From: Shel Kaphan <sjk@amazon.com>
Date: Thu, 29 Feb 1996 02:43:36 -0800
Message-Id: <199602291043.CAA16048@bert.amazon.com>
To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Cc: "David W. Morris" <dwm@shell.portal.com>, HTTP Caching Subgroup <http-caching@pa.dec.com>
Roy T. Fielding writes:
 > >> > I defy you to explain, for example, how Shel Kaphan can make his
 > >> > book-ordering server work in your user-wins model.
 > >> 
 > >> That's easy -- give the user an option at the outset regarding how
 > >> they would like to proceed.
 > > 
Such an option has to be able to affect the browser and its logic for
when to cache and when not to, not just the server, so to control that
from a server application there would have to be some representation in the
protocol. 


 > > You are wrong on this one Roy. There are a class of applications for
 > > which any alternative other than strict obediance to the server's
 > > intent would cause sever breakage. The PROTOCOL *MUST* support
 > > such applications.
 > 
 > Ahem.  There does not exist any conforming HTTP application for
 > which caching a response to a GET request would cause severe breakage.

"Ahem" yourself.  Sure there is.  If you want severe breakage, all you
have to do is keep a cached "shopping basket" page after it has been
modified by another user action that has not resulted in refreshing
that page in the client's cache.  If you don't believe this is "severe
breakage", you don't understand about the cost of customer support
when users get confused and call or send mail, or the cost of having
users just go away mad.   "I swear I put that thing in my shopping
basket, but when I look, it isn't there...your system is broken!"

 > That is one of the reasons why GET and HEAD have the semantics of a
 > retrieval and do not allow side-effects which would be significant to
 > the user's action.
 > 
 > .....Roy

That has absolutely nothing to do with it.  Side effects of 
other methods can affect resources that are retrieved with GET and
HEAD.

Incidentally, before you bring it up again:  while it might be a
useful research exercise to solve such problems with a new media type,
or with Java apps, or whatever, that is academic for anyone who has to
deploy real services before such things are widely available.

--Shel
Received on Thursday, 29 February 1996 11:14:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC