Re: caching dilemma

Jonathon Tidswell writes:
 > 
 > Shel Kaphan  <sjk@amazon.com> wrote:
 > | Kee Hinckley writes:
 > |  > At 10:20 PM 5/25/95, Shel Kaphan wrote:
	...
	 When you "back up" to an expired page,
 > | there are only three things I can think of that could happen:
 > | 1. you see the expired document.
 > | 2. you see an error message and (if you interpret the message correctly)
 > | 	you can reload the page manually
 > | 3. the browser reloads the page behind your back.
 > |
	...
 > Using a definition of history being that which actually happened, only 
 > (1) is actually correct.
 > This relies on the assumption that when I fetch a URL I want the URL at 
 > that point in time not, all URLs in future points of time.
 > 

I concur -- I have also been convinced that only option 1. is correct
(i.e. consistent, somewhat easy to think about).  However, will it be
possible to convince the authors of Netscape (which doesn't do it this
way) of this?  Unless it is, at this point some other solution will
have to be found, considering the statistic that 80% of the browsers
out there are Netscape.

There are several ideas floating around about how to
get the functionality of preventing caching of dynamic pages while
also preventing them being reloaded when they are visited with history
commands, but however it is implemented, there has to be some way of
accomplishing it.  (the other ideas involve interpretations of the
meaning of the presence or absence of various header fields).

 > |  > >document.  It is REALLY BAD for browsers to display cached copies of
 > |  > >expired documents when they are meant to be freshly displayed in
 > |  > >response to a direct user command, because a URL may be a request to a
 > 
 > I think consider the following case clarifies the issue (it did for me).
 > History is not kept off screen but each new URL creates a new window.
 > Going back through history in this model is simply flicking back in the 
 > window stack.
 > Given that the URL in question has been continuously visible is it 
 > appropriate to delete it / reload it just because it is now the top 
 > window, not the second top window.
 > 
 > - JonT
 > 

I have another example that convinced me: suppose you display a page
containing a form.  This page is "dynamic", i.e. it is the result of a
computation and may be composed differently at different times or for
different users.  A simple example would be that the page displays
some real-time stock quotes as well as the form.  By the current rules of
the game, in order to "make sure" (ha!) that no browser or cache holds
on to this soon-to-be-obsolete page, it is set to expire immediately.
The form is large -- let's say it has 50 input fields.

So, the user fills in the form and submits it. But the user made a
mistake. (It does happen sometimes...)  Let's say she forgot to fill
in some required field.  The easy thing to do would be to display a
page describing the error and requesting that the user go "back" to
the form, correct it, and resubmit it.  Some users will "go back"
anyway, no matter what instructions you give.  With Netscape or other
browsers using similar algorithms, this wouldn't work, because when
you go back, the browser would reload the form (since it has expired),
so your user would have to fill it in from scratch.  Bummer!  That
form had 50 fields -- way too much work to type it all in again.  So
the user leaves your site and never comes back.  (This is a
pedagogical argument -- don't complain that 50 fields is too many).

The way out (for Netscape and equivalents) would be to gather all the
incomplete information from the form when it was submitted the first
time, and on the "error message" page tell the user to click on some
link (instead of using the browser "BACK" button), and when they do,
you'd have to redisplay the form with all the fields preloaded.
That's kind of a lot of work for something so easy.

The moral is that history is history, and browsers should not be so
Orwellian (or is it Stalinistic?) as to rewrite it.

--Shel Kaphan
  sjk@amazon.com

Received on Wednesday, 7 June 1995 13:26:28 UTC