Re: Tracking hits without cache-busting

Grahame Grieve:
>
>
>>>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.
>>
>>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.
>
>It's not only IE5 either
>
>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

Yes, I am aware of the problems for highly dynamic applications.  The
difference between back and clicking a link does make things more
subtle for the user.

Some history: the distinction between the 'back' button and clicking a
link, or more generally the distinction between 'history functions'
and 'a new HTTP request through the browser cache', got encoded in the
(then-draft) HTTP spec around the end of 1995.  At that point, some of
the popular browsers had their history functions behaving like a cache
(refreshing the page if needed), others (notably the older one --
Mosaic) had them like we have them now (showing the old page even if
stale).  We (in the http working group) decided that it would be more
convenient for web application designers if all back buttons behaved
the same way.  Of couse, then we had to chose which way.

One reason to prefer 'back' as being separate was that this is what
the original Mosaic had.  People were used to their (static or
dynamic) content being re-displayed within a fraction of a second on
pressing 'back', without any network traffic.

The main reason why we chose to make 'back' and the history functions
separate from caching was that not doing so would make using 'back'
very costly when browsing dynamically generated content which was
labeled as such (the responses being labeled as pre-expired).  We
reasoned that most dynamic content did not need the property of being
regenerated when going 'back'.

We were afraid that, if 'back' always caused revalidation (and the
associated network delays), this would discourage too many people from
marking their dynamic responses as pre-expired.  This was at a time
when the ability to explicitely mark dynamically generated content as
pre-expired for shared caches was still somewhat of a novelty, and we
did not want to make this novel good thing unusable because of the
still-newer back button developments.

But it was really a bit of a tradeoff, if we had chosen to make 'back'
revalidate expired responses, this would arguably have been better for
highly dynamic applications, especially because of the reduced
complexity for novice browser users.  We were aware of the issue at the
time, in fact I created a highly dynamic application for novice users
before proposing (with Shel Kaphan) to standardise the current way of
decoupling 'back' from caching.  If we had gone the other way it would
have been years before we could have relied on the 'back' button always
refreshing content on all platforms anyway.  We also proposed a
'history-control' feature to influence 'back' at the time, separate
from 'cache-control', but this did not gather enough support to get
into a spec.


>Grahame

Koen.

Received on Tuesday, 29 June 1999 14:30:36 UTC