Update Apr 8 2009: Apparently this bug existed in previous Safari versions (at least back to 3.1), i.e. including “must-revalidate” in Cache-Control means Expire and max-age will both be ignored by Safari. Here’s the Apple bug, if you happen to be an employee. I created an Apple account but still couldn’t find it.
Short version: Safari 4 beta incorrectly interprets the Cache-Control “must-revalidate” directive and re-requests the file each time despite freshness info sent via “max-age”.
Long version
When a server sends Cache-Control with “must-revalidate”, this tells clients/caches that, after it expires, the cached resource should not be used without first checking with the server (sending a conditional GET). From the spec (my emphasis):
When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. [HTTP/1.1]
In other words, while the cache is fresh, there’s no need to revalidate.
E.g. I serve this Javascript file with the header “Cache-Control: public, max-age=1800, must-revalidate”. This tells clients: “consider this fresh for 30 minutes, then check back before using it again”. Unless you force a refresh, the browser won’t re-request the file for 30 minutes, after which it will send a conditional GET request. If the file hasn’t changed, the servers returns a “304 Not Modified” and the same Cache-Control header. This tells the browser to keep using the cache for another half hour and check back again. (Yes, half an hour is too short, I’ll change this later.)
Well, Safari 4 beta re-requests the file each time it needs it, seemingly ignoring the “max-age” directive. At least it’s sending a conditional GET, but it’s still a waste of bandwidth and time.
Apparently this a bug in webkit’s underlying network framework (now over a year old), but sending the Expires header USED to make it behave correctly.
I’ve seen and/or reported quite a few Safari bugs that have been closed invalid or wontfix with the excuse that the problem is actually in the “underlying network framework”.
This has given me the impression that Safari’s underlying network framework is an utter piece of shit that Apple is uninterested in fixing.
Although claimed by Apple as fastest browser, I dont think its qiute that fast! I have used many other browsers and feel that google crome is the fastest of them all. By the way they have added new features such as “cover flow” which I like very much.
Ryan: Bugs filed against WebKit at http://bugs.webkit.org/ that are problems outside of WebKit, the originator will typically be asked to instead file the bug at http://bugreporter.apple.com/. This is not because there is no desire to fix the problem, but purely because if the bug isn’t in WebKit then WebKit’s bug database is entirely the wrong place to track the issue.
At least the new bug (w/ test case) I created has been referred to Radar (Apple).
BTW I found this while trying to figure what its new “Speculative Loading” feature actually does.
Apparently this bug existed in older Safari versions as well. My test case is failing to show it in Safari 3.x because there’s a proxy intercepting conditional requests to mrclay.org that I was unaware of.
I’m very interested in this, as well, because I’m having the same problem.
hmm ive got a problem with a php script i wrote that serves up mp3 files that are located outside of the visible webserver hosted folders on the server.
the script SHOULD cache the mp3s it serves on the client and it works great EXCEPT in safari. sounds like it could be this? Ive tried the latest v4 betas and its no better.
Webkit bugzilla e-mails tell me a fix might’ve landed in the trunk, so this might actually get resolved.
In the meantime, probably best to just leave out “must-revalidate”.