Re: Semantics of ENTRY_NEGCACHED

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