...
Transmission fixity provides a means to verify the integrity of the binary content when ingested, that is when it is transmitted to the repository. When performing a PUT or a POST of binary content, you can supply the SHA-1, SHA-256, and/or MD5 digests for the binary resource in a request header. If you provide any of these digests on ingest, Fedora will internally calculate the binary's checksum and compare it to the provided digest. If they match, the binary will be stored and an appropriate response (HTTP Code 201 usually) sent to the client. A mismatch will result in a HTTP 409 response. Unless a a digest value is included on ingest, Fedora will create and store the SHA-1 digest for the binary resource.
...
Prior to Fedora 5, a user could invoke the /fcr:fixity service on a binary and the repository would perform the digest comparison for you and report whether the values still matched (or not). NOTE: While this service may still be in the code base and functional, the service has been deprecated. In conjunction with the /fcr:fixity service, it was possible to alter the default fixity checking algorithm used by the /fcr:fixity service on a per-resource basis. The default algorithm Fedora uses is SHA-1. For more information on this deprecated feature, see RESTful HTTP API - Changing the default fixity checking algorithm.
...