2

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

1 Answer 1

8

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 the Last-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 explicit max-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.

4
  • 1
    You say that "caches are allowed to calculate their own heuristic freshness". Is there a supporting RFC statement backing up this?
    – Pacerier
    Aug 25, 2013 at 7:17
  • RFC2616, along with draft-ietf-httpbis-p6-cache, which will soon replace it (as far as caching goes). Aug 26, 2013 at 7:44
  • Are you aware the timeframe when the draft is scheduled for release?
    – Pacerier
    Aug 27, 2013 at 8:23
  • Soon. It's post-Working Group Last Call now, and should be in IETF Last Call by mid-September. With any luck it'll be an RFC by the end of the year. Aug 28, 2013 at 23:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .