It would need to be done via the pointer-to-content (URL/URI), and an independently-calculated secure-hash, not just a header. (The 'ni' proposal might serve this role.[1])

You definitely wouldn't use MD5, as experts have been recommending against its use for content-security since about 1996.[2] (A practical full chosen-preimage attack hasn't yet been developed, but still, you'd design for security for the next few decades, which would mean a SHA256 or better.) The choice of a good hash would mean no one could practically create an alternate file with the same hash.

[1] http://tools.ietf.org/html/draft-farrell-decade-ni-10

[2] http://en.wikipedia.org/wiki/MD5#cite_note-30

Yes it would be possible because MD5 has been broken: https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities

Any file can be modified to result in a hash collision with a specific MD5. This makes is unsuitable for its stated purpose as a cryptographic hash.

The solution would be to use a newer and stronger hash like Keccak.

A solution similar to what you are thinking of is already used by Bittorrent's Distributed Hash Table to identify files.

To be precise, while MD5 has been 'broken' in the sense of not meeting its design goals for a long time, and there are now a number of scenarios where attackers can create pairs of files with the same MD5, it is not yet practically possible to create a collision for any arbitrary file (such as jquery.js) on demand. That would be the total 'preimage vulnerability' as mentioned at:

https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability

MD5 should absolutely not be used for this content-identification purpose or any other new code... and wise designers haven't been using it for 10+ years. I'm just mentioning this to be precise about the current state of its proven weaknesses.