14.15 Content-MD5
The Content-MD5 entity-header field, as defined in RFC 1864 [23], is an MD5
digest of the entity-body for the purpose of providing an end-to-end message
integrity check (MIC) of the entity-body. (Note: a MIC is good for detecting
accidental modification of the entity-body in transit, but is not proof
against malicious attacks.)
Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
EDIT: I don't know if any browsers actually support this. I just configured an incorrect Content-MD5 header for a page and visited it in Chrome, Safari and Firefox and none of them complained about it.BT is pretty awesome, I'd love to see it become a standard file distribution mechanism.
BitTorrent is also overly inefficient as a download protocol. It only makes sense in situations where you have extremely large flash crowds (WoW for example sending multiple GB to 14 million players in a few days) or the original source isn't in a position (legally or technologically) to source more than a few downloads.
The final nail in the coffin is the fact that a few major CDNs tried peer-to-peer for content delivery. The major broadband ISPs were none too pleased with their last-mile infrastructure (the most expensive part to deploy mind you) being abused. Their networks were designed for consumption, not distribution.
Secondly, there's been multiple times where I've downloaded a large file and found it was corrupted. Under conventional protocols you can't easily identify the part that is damaged, so even if it's only a small part (because WiFi dropped or whatever), you have to redownload the whole thing. Instead of doing that, I have just created a torrent, uploaded to openbittorrent, and downloaded the few megabytes I still needed.
I agree it may not be worth it to torrent small files (maybe <50MB), but I am not so pessimistic. As far as ISPs go, they just have to accept that their customers are going to be uploading much more than they have been and provide whatever infrastructure upgrades are required. I have no pity for that situation and I don't think it's a valid excuse to not see wider-spread usage of BitTorrent as a conventional download mechanism (i.e., baked into browsers, looks like a HTTP download). They can even default browsers to upload at a low rate, like 5Kb/s, or even 0Kb/s, and be fine; the benefits we're discussing now are inherent in the protocol, not necessarily the size of the swarm; we can still expect content providers to provide the machines that upload all of their content and allow seeding as opt-in only, and see big improvements from the usage of the BitTorrent protocol.