W3C home > Mailing lists > Public > www-talk@w3.org > May to June 1999

Re: Tracking hits without cache-busting

From: Daniel LaLiberte <liberte@w3.org>
Date: Tue, 29 Jun 1999 13:11:37 -0400 (EDT)
Message-ID: <14200.65097.733720.920908@alceste.w3.org>
To: www-talk@w3.org
   Daniel LaLiberte wrote:
 > >>But IE 5 might have a bug regarding this must-revalidate feature: it
 > >>doesn't redisplay a page when you revisit it from your history with Back
 > >>and Forward keys until you hit enter in the location field, or something
 > >>like that.

Grahame Grieve writes:
 > >That is not a bug in IE5, that is the exact behavior required by the
 > >standard.  Back is supposed to show the old page you have seen before,
 > >not fetch a new copy.  See for example section 13.13 of rfc2616.

Well, I was not very precise, so everyone misunderstood me.  By "it
doesn't redisplay a page when you revisit it from your history" I meant
that it doesn't display *anything at all*.  Nothing - blank page.  I
don't believe this is the intent of the must-revalidate feature.  If you
want to see this in action, using IE 5, you can visit the following URL,
click on one of the reply messages, then go back and forward.
http://www.hypernews.org/HyperNews/get/hypernews/future/65/1/1/1.html

 > It's not only IE5 either

I don't know of any other browsers that behave as I described for IE5.

 > but this is obtuse to a user. why should a user perceive 
 > any difference between a page they got from going back 
 > and a page they got from going forward? In highly dynamic
 > web applications this caching of back business is a big problem with 
 > the http standard

I agree the history is confusing to users.  But I find they don't want
to use it at all, and I don't think the confusion is the main reason.

 > I settle this by trying to prevent the user from 
 > desiring to use the back button at all. in some ways 
 > this only makes things worse, of course, but there you go.

Prevent?  I imagine that JavaScript might be used to detect the event of
revisiting a previous history page, so it can then display something
different.  But I would find this much more annoying generally.

The only case where the browser history should be messed with is where
reusing a history page could result in the wrong thing from the user's
perspective.  There are legitimate cases of that, or at least there are
ambiguous cases.  Shopping basket applications are a good general case;
are you going back to a previous version of the shopping basket, or adding
something to the "current" shopping basket.

 > my stategies are to provide key links on toolbars and make sure
 > back links are integrated with the text where the user
 > would perceive a reason to go back. And I always do a redirect
 > after a post.

How does a redirect help?  I suppose it will avoid the problem of
reposting the form that resulted in the page, which browsers shouldnt do
unless acknowledged by the user, and only if a reload is required for
some reason.  Is that all or are there other side effects.

-- 
Daniel LaLiberte
liberte@w3.org
Received on Tuesday, 29 June 1999 13:11:40 GMT

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