Fedora supports two types of fixity: Transmission fixity and persistence fixity.
Transmission Fixity
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 When you ingest a binary resource into Fedora, you have the option of providing any or all of the following digests for that resource: 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 and verify a match with the binary's checksum and compare it to the provided digest(s).
RESTful HTTP API - Containers#Containers-post-example4b
The digest values . 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.
See RESTful HTTP API - Containers, POST, Examples 4 and 4b
Persistence Fixity
Persistence fixity provides a means for you to compare an on-demand digest calculation to the (original) stored values, which are saved as server-managed you provide will be stored by Fedora as values on the "premis:hasMessageDigest" property.RESTful HTTP API - Changing the default fixity checking algorthm
...
Users can perform a HEAD or GET request on a binary resource and include, as part of the request, a Want-Digest header, indicating that the server should recalculate the message digest per the provided algorithm and return the calculated digest as part of the response headers. In this way, the client can compare the calculated value with the stored value to determine the integrity of the on-disk stored content. A mismatch suggests some form of binary corruption and the repository manager should investigate and take appropriate actions to remediate.
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.If you do not provide any digest on-ingest, Fedora will create and store the SHA-1 digest for the binary resource.
Subsequent to ingest, you can request that Fedora recalculate and verify the binary resource's digest against a stored value. By default, Fedora recalculates and compares the SHA-1 for this on-demand fixity checking. If, however, you would prefer that Fedora verify against one of the other digests that you provided at the time of ingest, you can configure Fedora to do that by creating the property "fedoraconfig:defaultDigestAlgorithm", and setting it to any of the following values: SHA-1, SHA-256, MD5