W3C home > Mailing lists > Public > www-talk@w3.org > March to April 2000

Re: Enforce reloading of page when using the back-button

From: Arjun Ray <aray@q2.net>
Date: Wed, 8 Mar 2000 21:19:15 -0500 (EST)
To: www-talk@w3.org
Message-ID: <Pine.LNX.4.10.10003082058500.12107-100000@mail.q2.net>


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 GMT

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