The hash is not for cryptographic purposes, it's to detect corrupt downloads. Ideally you should provide both the hash and you should pgp sign your releases.
(A quick Google shows that indeed it can be: the Content-MD5 header <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html>. Wonder how widely supported it is by HTTP software used by people who like to check hashes of things they download.)
(Although I will note that file systems, like application protocols, should maintain their own integrity; however most do not. Which also seems bizarre given that it's 2014.)
(My day job is working with enterprise-grade content-addressed block storage, so maybe I've just set my data-protection expectations too high.)
Both of these options would protect your important files against failing single disks without having to do any RAIDing. The unimportant data (e.g. the OS itself, caches, etc.) could be reduced-redundancy, since it doesn't need to be captured in a disk rescue.
For any archival DVDs I burn, I compress, then run through PAR2 http://en.m.wikipedia.org/wiki/Parchive
In the real world there are bugs in TCP stacks and in HTTP implementations that cause HTTP traffic to get corrupted. I see this every day. Some applications do implement extra checking, most applications do not. Browsers and wget and curl can't implement any extra checking because the way you check is application specific. There is no standard way to do it; what you mention there is an esoteric feature.
Just for anecdotal fun, Logic Pro tries to download over 50GB of assets over HTTP (each individual file is many-GB). It has never worked for me over any of my networks (and in fact I wrote a tool to fix this).
I'm very much aware of this. Hence why I expressed surprise that such checksumming was not commonly performed at the application layer.
> There is no standard way to do it; what you mention there is an esoteric feature.
The Content-MD5 header is defined in RFC 2616. It is, by definition, standard. If it's not widely supported, then I think that it would behoove the people who care about these things to switch to servers/clients which do support it.
(I suspect the intersection between "people who know/care how to use md5sum" and "people who know how to set/read an arbitrary HTTP header" is fairly large. Hence my surprise at the common practice of ignoring this capability.)
* Checksums, like in Xmodem or CRC
* Cryptographic hashes (including MACs)
* Cryptographic signatures (ie OpenPGP key or cert)
To say that it is difficult to implement all of these correctly and in concert is a grave understatement, but this is what modern crypto software and network protocols that use it, have to do.
Now back to the thread on HTTP header checksums :)
I don't know the root cause in general, but for me the most common cause has been bugs in the TCP/IP stacks of cheap home routers.