On Sun, 1 Mar 1998, Henrik Nordstrom wrote:
> It seems that I have to clarify what I said before.
Sorry if I didn't/don't "get it" - it's been a long night/weekend. ;-)
> The problem is NOT user-forced refreshes (Pragma: no-cache). These
> always go direct if possible, else trought a parent. The problem is a
> race condition, where your cached object expired/got purged in the time
> between our ICP HIT reply and the HTTP query from the neighbour.
Understood. Given the dearth of complaints we've seen around here lately,
I can only assume that this race condition is pretty rare, no? (Though of
course just relying on that fact alone isn't a "fix".)
Also if user-forced refreshes are meant to be going direct or via a
parent, then why am I getting "TCP.*REFRESH" requests from neighbour
proxies? Have I been configured as a parent (which would still be
rendering "miss_access" as useless)?
> You should not deny a correctly configured neighbour miss_access, as
> this may break fully legitime queries where your cache returned a HIT
> but then changed its mind before receiving the actual HTTP query.
What about just ignoring the refresh component of the request (rather than
denying the request altogether)? I mean, if refresh requests are meant to
be going direct/via parents anyway...
Cheers, and thanks..
dave
Received on Sun Mar 01 1998 - 17:37:41 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:39:07 MST