Re: Fwd: [Squid Bug 1548] - TCP_REFRESH_HIT/TCP_REFRESH_MISS do not update Squid's opinion of an object's freshness

please keep discussions on the mailinglist (or bugzilla)

tis 2006-05-02 klockan 00:22 +1200 skrev Doug Dixon:
> I thought about that.... it's kind of a weird case.

Yes, it is.

> http://www.squid-cache.org/Doc/FAQ/FAQ-6.html#ss6.7 says:
>
>
> TCP_REFRESH_MISS
> The requested object was cached but STALE. The IMS query returned
> the new content.
>
> TCP_REFRESH_HIT
> The requested object was cached but STALE. The IMS query for the
> object resulted in "304 not modified".
>
> But neither is true. It's more like a TCP_OFFLINE_HIT except this
> would make people wrongly assume they had offline_mode on.
>
>
> We could have a new code: TCP_REFRESH_FAIL_HIT which would be good
> because it alerts admins about their origins serving errors... but it
> does add to an already big list.

Looking in the code.. it's already there and used for a few cases where
refreshes was unsuccessful. So continue using it sounds like a good
idea.

> On the other hand... is a HIT something we don't have to query the
> origin for? If so they should all be misses:
>
>
> TCP_REFRESH_UNMODIFIED <- origin said 304
> TCP_REFRESH_MODIFIED <- origin said non-error, non-304
> TCP_REFRESH_ERROR <- origin said error

Perhaps. It's kind of a FAQ to explain these...

> I don't mind which way we go on this, it's pretty minor compared to
> the actual fix :)

Lets try to separate the two issues. First fix the behaviour, then
separately consider if the log codes should be changed.

There is more changes to the log codes which may be interesting, but
changing these should not be taken lightly as it has direct implications
on existing log processing tools who have already learnt the existing
terminology (at least some.. some do get it slightly wrong sometimes,
but refreshes is by nature "odd" in terms of hit/miss)

Regards
Henrik