Thanks for your comment. I did some testing in Safari and it revalidates the cache *before* it goes stale. However, after some more testing it seems that Safari is kinda special in this. Opera and Firefox do not show this behavior.

I should also note that Safari revalidates in an asynchronous way, it first shows you the cache and then puts the validity check on some sort of queue. Closing the browser before it fires the conditional-get does not clear this queue so it seems, as reopening simply fires a ‘if modified since’ request.

From reading the specification:

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.

It seems to only say how to handle the ‘must-revalidate’ directive AFTER the cache goes stale. And when interpreting the next part:

Servers should send the must-revalidate directive if and only if failure to revalidate a request on the entity could result in incorrect operation, such as a silently unexecuted financial transaction. Recipients MUST NOT take any automated action that violates this directive, and MUST NOT automatically provide an unvalidated copy of the entity if revalidation fails.

One could say that the gist of providing a 1.3 version by the CDN is this: “always make sure the client has the latest (bug free / patched) version of the library”. If that is the case, then the cache control setting ‘must-revalidate’ is indeed correct but setting a cache expiry time of one hour isn’t imho.

ps,
You’re right that when the cache expires, the browsers do not automatically purge the item from their cache. At least not in the 1 hour interval i have tested. I have modified my post accordingly, thanks!

So, what really happens when you use jquery version 1.3 from Google? The cached version will be used for 1 hour without revalidation, then the content will be revalidated once every hour to make sure it hasn’t changed. If the content hasn’t changed, the revalidation request will be a lightweight 304 (Not Modified) response, thus avoiding an unnecessary 60k download.

Let me know if I’m misunderstanding something myself. See http://www.freesoft.org/CIE/RFC/2068/168.htm for details.

…On the other hand, the “time travel” issue for libraries with URL parameters is a completely separate issue. It seems that caching is disabled for requests with URL parameters. Maybe that’s a bug.

Cache-Control:public, must-revalidate, proxy-revalidate, max-age=3600

So, if the version changes the client will download the new version independent of the expires header.

jQuery 1.3 is linked to last version. Setting the expiration time for one hour is complete understable – maybe new version will be released in next hour?

However, your final note is correct.

I’ve never used a CDN before, because I’m kinda scared to download a JS file from a third party servers. I tried to avoid this as much as possible. And your post gave me one more reason for me to avoid CDN!

Page load is getting more and more important. People do not accept to wait, page load time already influences your bounce and conversion rates and might soon even influence your search ranking.

But yes, it is wrong to talk about bandwidth in the title, but then again the complete title is somewhat exaggerated. As it is not really Google who is screwing up your latency it is the misuse of their CDN which is at the heart of the problem.