[11521] in www-talk@info.cern.ch
Re: Enforce reloading of page when using the back-button
daemon@ATHENA.MIT.EDU (Arjun Ray)
Wed Mar 8 21:21:06 2000
Date: Wed, 8 Mar 2000 21:19:15 -0500 (EST)
From: Arjun Ray <aray@q2.net>
To: www-talk@w3.org
In-Reply-To: <200003090941.AA1303774094@melb1.kestral.com.au>
Message-Id: <Pine.LNX.4.10.10003082058500.12107-100000@mail.q2.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-From: 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
