In case of hits on stale objects for which a 304 was returned by the origin as a response to the resulting conditional request, Varnish considers the lookup overall as a cache hit. ATS is more specific and distinguishes between TS_LUA_CACHE_LOOKUP_HIT_FRESH and TS_LUA_CACHE_LOOKUP_HIT_STALE. During the migration to ATS we decided to follow the interpretation used by Varnish and added the following Lua code to ats-be:

if status == TS_LUA_CACHE_LOOKUP_HIT_STALE then
    -- We have a cache hit on a stale object. A conditional request was
    -- performed against the origin, which replied with 304 - Not Modified. The
    -- object can be served from cache. Arguably this is not exactly a "hit",
    -- but it is more of a hit than a miss. Further, Varnish calls these "hit",
    -- so for consistency do the same here too.
    if ts.server_response.get_status() == 304 then
        return "hit"
    else
        return "miss"
    end
end

For this reason, we are currently classifying requests that resulted in a conditional request by ats-be to the origin as hit-local if the origin responded with 304. It would be useful to revisit X-Cache-Status and:

1. get rid of {hit,int}-remote as we now only have a cache frontend and a dc-local backend, no remote caches anymore
2. distinguish between: hit: cache hit on a fresh object, hit-stale: cache hit on a stale object, the origin said it hasn't changed (304) , miss: object not in cache, miss-stale: cache hit on a stale object, the origin said 200