- From: Arjun Ray <aray@q2.net>
- Date: Wed, 8 Mar 2000 21:19:15 -0500 (EST)
- To: www-talk@w3.org
On Thu, 9 Mar 2000, Grahame Grieve wrote: > ><clue>The browser is *mine* to use, not *yours* to command.</clue> > > I don't think it's so simple, On the contrary, it *is* that simple... > else there would be no commands relating to caching at all. ... because there are indeed no *commands* related to caching. The model in the HTTP/1.1 spec is sophisiticated enough as it is. > It's a 2 way street. Um no. > For my data in this application, the data is the *servers* and the > *user* accesses it at the data owners discretion. That's right. In client/server, the server has the right to refuse, that's all. > It's highly unsociable to prevent caching of static public content > - and why would you want to? But secure dynamic content? How can > you allow caching? You are missing a fundamental point. Caching is one thing, and the back-button is another. Please see RFC 2616, Section 13.13 "History Lists": History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved. That's a *given* of browser functionality. An application that sees fit to demand petulantly that something be done about this, wasn't really for the web to begin with. Arjun
Received on Wednesday, 8 March 2000 21:14:31 UTC