Mark Nottingham wrote:
While digging around to create bug 2468, I started wondering about what
ENTRY_NEGCACHED really means.
I interpret "negative caching" as "using a heuristic -- namely, that
something is an HTTP error -- to make something cacheable." This is why
I don't complain about the neg caching code being surrounded in #if
HTTP_VIOLATIONS.
However, error responses can have an explicit freshness lifetime set in
their headers, just like "normal" responses. In these cases, it seems to
me that we shouldn't mark them as ENTRY_NEGCACHED, because we're *not*
taking any liberty with their freshness.
I.e., I'm wondering if it makes sense to move
EBIT_SET(e->flags, ENTRY_NEGCACHED);
to be part of
if (expires == -1)
expires = squid_curtime + cc.negative_ttl;
in storeNegativelyCache.
The most visible impact of this is that a 404 (etc.) response with a
Cache-Control: max-age (or similar) would show up in logs as a TCP_HIT
rather than TCP_NEGATIVE_HIT. From browsing the code, there would be a
number of other smaller but I think sensible impacts (e.g., it can be
put into a digest, and stats are cleaned up).
Thoughts?
You have a good point.
I don't think the POS/NEG should be combined though. NEGCACHED has clear
info for debugging websites which return error pages.
A better way would be to add a third state STALE or somesuch, for the
actual violations.
Just my 2c.
Amos
--
Please use Squid 2.7.STABLE4 or 3.0.STABLE9
