Noticing the same Phoenix/Mozilla/(others?) behavior this morning (like most mornings) where loading my LJ friends page gave me an old cached copy (straight from disk, I just booted the machine and ethereal showed no HTTP traffic to LJ when I loaded the page, both times, although it did hit on reload/refresh), I decided to check the headers and noticed the Cache-Control line of "private, proxy-revalidate". I'm used to "private" since I see correctly-behaving IIS servers send that along with ASP output all the time. I was pretty unfamiliar, however, with proxy-revalidate, so I checked the first google hit for
cache-control private proxy-revalidate and got
this Jigsaw page which seem confusing.
why not just Cache-Control: private? The added ", proxy-revalidate" seems to fall under a
cache extension, right?
While I could imagine the proxy-revalidate would seem to make sense on the surface, while reading through the section on
Cache Revalidation and Reload Controls, the last entry is on proxy-revalidate and states 2 specific things:
1) "does not apply to non-shared user agent caches", so this doesn't make much sense since we're specifically disallowing shared caches already with the "private" header.
2) "Note that such authenticated responses also need the public cache control directive in order to allow them to be cached at all." which agrees with the first in that this response shouldn't be cached at shared caches since we didn't tag it as public
did a google for "site:livejournal.com caching" to see if existing caching behavior was already explained somewhere, but nothing seemed like a good match.
Thanks!