- From: Shel Kaphan <sjk@amazon.com>
- Date: Thu, 29 Feb 1996 02:43:36 -0800
- 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