Nope, that's not the way web client caching works, at least not in
practice.
The whole point of a client-side cache is to reduce the number of
round trips to the server. So if I send a packet to the server and say "hey,
ah, has page foo.html changed since I cached it at 12/25/00 12:34:56?" And
it replied with "no change", I'm still no better off than if I'd just said
"gimme the current foo". Either way, I've made one round trip. OTOH, if foo
*has* expired, then I have to go back and ask for it, which means I'm
actually doing 2 round trips and am worse off than if I'd just demanded it
from the get-go.
So what ends up happening is that most web browsers have rules of
thumb they use to let them "skip" a lot of these "freshness checks". Things
like only checking for freshness once per session.
So the general rule of thumb most browsers follow is:
Don't bother checking the server unless:
A) It's expired.
B) This is the *first* time we've looked at this page this session.
So it's up to the web server to put expirations and/or no-cache
statements. Especially for highly dynamic data, you really want to just
stuff a no-cache in there and be done with it. Otherwise you'll get some
serious weirdness where, for example, the "first" read of a session will be
clean, but subsequent reads wont, etc.
The other thing to beware of is that the HTML spec allows a *lot* of
wiggle room on how the browsers cache. As a result you'll often find
situations where two browsers will use different caching rules and exhibit
different behaviors.
Here's a decent overview of the caching process.
http://www.web-caching.com/mnot_tutorial/how.html
--- Pat
> -----Original Message-----
> From: Kevin Menard [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 17, 2005 2:11 PM
> To: Tapestry users
> Subject: Re: Opera Caching Issue
>
>
> On Jul 17, 2005, at 4:26 PM, Patrick Casey wrote:
>
> >
> > Did you add a pragma-nocache entry to your html header?
>
> Nope, thus my question at the end. But the gist of my post is why
> must this be done? Shouldn't Opera consult the web server and ask if
> the file has changed before it uses a cached copy? If so, who's to
> blame here?
>
> --
> Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
