Docs

Torch Object Storage

Checking data integrity

Overview

Cybersecurity incidents such as network hijacking or data caching outside the TOS environment may cause data inconsistencies when you upload or download data to or from TOS via the Internet. To ensure data integrity, TOS provides two solutions to verify uploaded and downloaded objects. This topic introduces the related concepts for these two scenarios.

Related concepts

Content-MD5

Content-MD5 is a standard HTTP request header field, defined by the HTTP protocol, that represents a fingerprint value of the request message body data. This value is generated by calculating the hash of the data using the MD5 algorithm and encoding it as a Base64 string.

TOS APIs, such as PutObject and UploadPart, use the Content-MD5 header to carry the MD5 checksum. Additionally, the PostObject API can include this value in the form fields. TOS independently calculates a checksum of the data using the same algorithm and validates it against the provided value. If they do not match, the upload fails and the object will not be saved.

Content-SHA256

Similar to Content-MD5, Content-SHA256 is a request header field defined for TOS scenarios that represents the fingerprint value of the request message body data. However, it uses the more secure SHA-256 algorithm to generate a string by hashing and encoding the data in hex.

TOS APIs, such as PutObject and UploadPart, use the x-tos-content-sha256 header to carry the SHA-256 checksum.

CRC-64

The CRC-64 algorithm is a commonly used cyclic redundancy check algorithm to verify data integrity. Learn more in Cyclic redundancy check.

TOS APIs, including PutObject, PostObject, UploadPart, GetObject, HeadObject, and CompleteMultipartUpload, use the x-tos-hash-crc64ecma header to carry the CRC-64 checksum.

warning

CRC-64 check is a new feature. For objects uploaded before its implementation, the GetObject and HeadObject responses may not include the CRC-64 checksum.

When the Range parameter is used with GetObject, the value returned in the response header is still the CRC-64 checksum of the entire object.

Object lists retrieved using ListObjects or ListObjectVersions now include a new field representing the CRC-64 checksum of each object.

Last updated: 2026.08.25 10:39:45