Current Release

This documentation covers the current version of Fedora. Looking for another version? See all documentation.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Fedora supports two types of fixity operations: Transmission fixity and persistence fixity.

For these operations, Fedora supports the following digest algorithms:

  • SHA-1
  • SHA-256
  • SHA-512
  • SHA-512/256
  • MD5

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 one or more digests for the binary resource in a request header.  If you provide a supported digest, 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.

Digests provided in this manner will be stored as metadata in Fedora, and can be found under the <http://www.loc.gov/premis/rdf/v1#hasMessageDigest> predicate when requesting the fcr:metadata resource for that binary.

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 recorded digest values.  There are two approaches to persistence fixity.

On-demand Digest Calculation

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.

See RESTful HTTP API - Fixity

On-demand Fixity Check

An on-demand fixity check can be requested by making a GET request to the /fcr:fixity endpoint of a binary. This will recalculate the digests of each algorithm that is on record for the binary, and compare against those stored digests. The results of the check will be returned in an RDF serialization. See RESTful HTTP API - Fixity for usage.

Default Digest Algorithm

By default, Fedora will calculate and store a SHA-512 digest for all binaries if none were provided via Digest header. This digest will be available via the fcr:metadata endpoint for the binary, stored under a <http://www.loc.gov/premis/rdf/v1#hasMessageDigest> property.

The default digest algorithm used by Fedora may be set to either SHA-512 or SHA-256, via the fcrepo.persistence.defaultDigestAlgorithm option. This will affect the default digest for binaries, and will also determine the digest algorithm used for objects in OCFL.



  • No labels