Using trac, I'm getting a response with the following header:
Cache-control: must-revalidate
Moreover, no 'Expires' header is being sent. Our local proxy, however, is caching these responses, so when an edit is made, pages need to be 'hard refreshed' to update. Is the proxy misbehaving? Other headers that might be relevant:
Connection Keep-Alive
Proxy-Connection Keep-Alive
Keep-Alive timeout=15, max=100
HTTP allows responses to be cached, even if they don't have explicit Expires or Cache-Control headers.
Specifically, they're allowed to calculate their own so-called heuristic freshness for responses with certain HTTP status codes (including
200 OK
). Usually, this is based upon the value of theLast-Modified
header; e.g., if LM is 1 day ago when the response is first stored, a cache might figure that it's safe to assume it's fresh for 2 hours.must-revalidate
is an instruction that tells caches that once something becomes stale, it has to be checked on the origin server. If it isn't present, caches can (generally) use stale responses in unusual circumstances (e.g., if they lose contact with the origin server).So, no, this cache doesn't look like it's misbehaving, although it sounds like it might be a bit aggressive in calculating heuristic freshness. If you don't want the cache to store the response at all, try
Cache-Control: no-store
, or (preferably) just set an explicitmax-age
to control how long it's considered fresh.You might be interested in having a look at the IETF HTTPbis Working Group's current document that covers caching:
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p6-cache
which hopefully makes this a bit clearer than RFC2616.
Also, http://redbot.org/ will check URLs and explain how caches handle specific response directives.