jQuery's CDN and Far-Future Expire Headers

Question

Question

Why does content served from jQuery's CDN lack far-future expire headers? (or, "What am I doing wrong here?")

Background

I'm using jQuery and jQuery Mobile on a web project. To serve these scripts, I use jQuery's CDN, per their directions. However, I've noticed that these resources are served without far-future expires headers, which prevents browsers from being able to cache them intelligently.

Although the jQuery servers will respond with 304 Not Modified, that's not the same as an expire header the negates that request altogether. I realize the simple answer here is "because they don't" however, I'm wondering why they don't, and if there's some way I can serve this content, ideally from a CDN, with far-future expires headers.

Thanks for your time.

Examples

jQuery CDN

http://code.jquery.com/jquery-1.6.4.min.js

Response:

HTTP/1.1 304 Not Modified
Date: Wed, 16 May 2012 00:05:27 GMT
ETag: "9e68e84-16615-6ad9bfc0+gzip"
Last-Modified: Mon, 12 Sep 2011 22:55:03 GMT
Server: ECS (dca/532A)
Vary: Accept-Encoding
X-Cache: HIT

Google CDN

https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js

Response:

HTTP/1.1 200 OK
age:134505
cache-control:public, max-age=31536000
content-encoding:gzip
content-length:32103
content-type:text/javascript; charset=UTF-8
date:Mon, 14 May 2012 10:45:15 GMT
expires:Tue, 14 May 2013 10:45:15 GMT
last-modified:Mon, 02 Apr 2012 18:24:28 GMT
server:sffe
status:200 OK
vary:Accept-Encoding
version:HTTP/1.1
x-content-type-options:nosniff
x-xss-protection:1; mode=block

Note the far-future expires date in expires:Tue, 14 May 2013 10:45:15 GMT

Solution

I'm using Microsoft's CDN hosted version which features a 1 year expire date:

http://ajax.aspnetcdn.com/ajax/jquery.mobile/1.1.0/jquery.mobile-1.1.0.min.js

Full list of CDN hosted files.

@zuul explained below why some CDN hosted items have longer expire headers than others. Thanks!

Answer 1

The whole caching issue depends on the links you're using. I've observed that quite often people aren't linking to exact version numbers of jQuery.

For example, from code.jquery.com you can reference this file...

http://code.jquery.com/jquery-latest.min.js

... and you'll always get the latest copy of jQuery.

Or you can do something similar from Google...

http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js

That one from Google will get the latest version, assuming it starts with "1". The trouble is that when you use these references you don't get a far-future expiration date set in the cache-control header. Therefore the user's browser will be checking for updates much too frequently, slowing down your site's load times.

In fact here's a breakdown of several options and their expiration settings...

http://code.jquery.com/jquery-latest.min.js (no cache)

http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js (1 hour)

http://ajax.googleapis.com/ajax/libs/jquery/1.7/jquery.min.js (1 hour)

http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js (1 year)

By explicitly stating the exact version of jQuery you want Google sends back a max-age header of 1 year. So you're greatly increasing the chances that the client will simply use a cached copy. And if a new version of jQuery comes along with bug fixes or features you really want, then just update your link.

---

This explanation is originated from BucketSoft Blog