Semantics of ENTRY_NEGCACHED

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?

--
Mark Nottingham       mnot_at_yahoo-inc.com