Robot Trade Digests: Read Content-Digest and Repr-Digest

Two HTTP Fields, Two Different Objects

RFC 9530 defines HTTP fields that support integrity digests: Content-Digest for the integrity of HTTP message content, and Repr-Digest for the integrity of HTTP representations (RFC 9530). The distinction is not cosmetic. Message content is the payload carried in a specific HTTP message; the representation digest concerns the entire selected representation data. These scopes can coincide in some messages and differ in others; the field name and message context must be read together. A digest computed over one object does not automatically describe the other.

In robot trade file delivery, this matters because a seller might send a configuration archive over HTTP and quote a digest in a field. If the field name is Content-Digest, the digest covers the bytes of that message's content. If it is Repr-Digest, the digest covers the selected representation, which could differ from the raw file stored on disk if the server applies transformation. A buyer who treats either field as a generic "file hash" risks comparing the wrong object.

The RFC also defines Want-Content-Digest and Want-Repr-Digest for expressing a sender's interest in receiving the respective fields (RFC 9530). These are preference signals, not integrity guarantees. They tell the peer what the sender would like, not what has been verified.

RFC 9530 obsoletes RFC 3230 and its Digest and Want-Digest fields (RFC 9530). A trade document that still cites the older field names is referencing a superseded specification. The current standard separates the two scopes explicitly, and a delivery record should name the field actually used.

What a General File Hash Actually Describes

A hash function maps a bit string of arbitrary length to a fixed-length bit string, and approved cryptographic hash functions are designed to be one-way and collision-resistant (NIST CSRC glossary). That definition says nothing about HTTP. A file hash is a property of a particular sequence of bytes fed into the function. It does not carry information about which HTTP message, which representation, or which negotiation outcome produced those bytes.

When a hypothetical robot trade seller provides a file and a hash value, the value describes the input bytes under the stated algorithm. A reader still needs a trustworthy reference and an actual comparison to support a matching-bytes statement. It does not, by itself, identify how the file was delivered, whether the server transformed it, or whether the received bytes match the sent bytes. Those are separate questions that require observing the transfer and the fields exchanged.

Conflating a file hash with Content-Digest or Repr-Digest invites a category error. The HTTP fields are protocol elements with defined semantics; a file hash is a mathematical value. A delivery record should state which is being used and what object each value covers.

A Hypothetical Partial Transfer

Imagine a buyer requests a robot configuration file from a seller's HTTP server. The server begins sending the response, but the connection drops after only part of the content arrives. The buyer has some bytes and perhaps a Repr-Digest header captured from the response. No checksum has been computed over the partial data, and no claim is made that the seller is authenticated or that any security certification applies.

In this scenario, the Repr-Digest value describes the complete representation the server selected, not the truncated byte sequence the buyer holds. The partial data and the selected complete representation are different comparison objects. No calculated value or mismatch is asserted in this example. A reader should first identify what was actually received and which object the quoted field describes, rather than inventing the outcome of a calculation that has not been performed.

A documentation follow-up can ask the supplier to explain the transfer context and what evidence would support a complete-receipt comparison. The fictional record does not establish corruption, its cause, or that the supplier’s stored file is wrong. The digest field's scope limits what conclusion it can support.

Reading a Delivery Record Without Overclaiming

A careful delivery record for robot trade files should separate three things: the file as stored, the HTTP message that carried it, and the representation the server selected. A Content-Digest value applies to the message content; a Repr-Digest value applies to the representation. A standalone file hash applies to the file bytes. None of these automatically validates the others.

If a record lists a digest field name, the reader can ask what object that field covers under RFC 9530. If it lists only a hash algorithm and value without a field context, the reader should ask whether the value was computed over the stored file, the received message, or something else. The answer determines what comparison is meaningful.

For example, a record might note that a Repr-Digest header was present in the HTTP response and that a separate SHA-256 value was computed over the downloaded file after transfer. Those are two differently scoped records whose input bytes might or might not coincide. RFC 9530 includes a full-response example where the two HTTP fields have the same value, so different names must not be read as a guarantee of different bytes. Stating both, with their scopes, is more useful than collapsing them into a single "integrity check passed" line.

Keeping the Distinction in Trade Practice

Robot trade teams often exchange files through HTTP-based systems, and the terminology of digests appears in delivery notes, acceptance checklists, and supplier correspondence. The RFC 9530 distinction between content and representation is easy to lose when the file is small and the server does not transform it. But the distinction remains technically real, and a record that ignores it may later be read as making a broader claim than the evidence supports.

When reviewing a delivery, ask which digest field was used and what it covers. If the field is Content-Digest, the digest is tied to the message content of that response. If it is Repr-Digest, the digest is tied to the selected representation. If neither field is present and only a file hash is quoted, the hash stands on its own and does not inherit HTTP semantics.

This reading does not require assuming the seller is trustworthy or that the transfer is secure. It only requires naming the object a digest describes. That habit keeps the record honest and makes later review possible, whether the file is a robot configuration, a firmware image, or a trade document. For broader documentation reading, see technical information category and related resources category.