Change the URL in your HTML from
https://ajax.googleapis.com/ajax/libs/jquery/1.6/jquery.min.js
to
//ajax.googleapis.com/ajax/libs/jquery/1.6.0/jquery.min.js
Explanation:
The opening // instead of https:// is a shorthand -- supported by all major browsers -- which means "the same protocol as the parent page is using". In other words, if your own site uses SSL, then jQuery will be served over SSL. If not, then your users will use plain HTTP for jQuery, and benefit from the faster connection setup un-encrypted HTTP has.
When serving content with a full version number -- the 1.6.0 part -- Google's CDN will automatically use long caching headers. The URL you used means "the newest in the 1.6 series", and is served with shorter caching headers, so that Google can quickly update when jQuery releases a new version.
You can verify that this works with Rex Swain's HTTP Viewer if you'd like. (NB: this HTTP viewer doesn't support the // shorthand, but browsers do.)
I know this question is super old, but I just ran into the same issue. Make sure the user you are running nginx as has write privileges to the proxy_temp directory. If you are serving a larger response through your proxy server that can't all be held in your proxy_buffers, the rest of the response data gets written to disk in your proxy_temp directory. If it can't because of inadequate privileges (or something else, i.e. disk space), then the response gets truncated.
An easy way to tell is this is the issue is to clear your browser cache, and reload the page with Chrome developer tools open. Find the truncated file in the network tab, and if the size matches your proxy buffer size (64k in your case) then nginx is likely having issues writing to disk.
More info on the nginx proxy_temp_path: http://wiki.nginx.org/HttpProxyModule#proxy_temp_path
Best Answer
Neither. Use:
That will use whichever protocol your page was requested with.
See my reference here.
You should use this instead of linking to your own copy of this file on your server. It saves you bandwidth as you won't have to serve this file to your users (it adds up). And it makes the experience for your users better as they won't have to spend the 500 milliseconds downloading the file. Most likely, your users will have visited another web page which references Google API and will have jQuery cached. If they haven't they will pull that file from a server close to their location minimizing round trip time.
Don't let anyone convince you that this isn't the right thing to do.