3. The Repr-Digest Field
The Repr-Digest HTTP field can be used in requests and responses to communicate digests that are calculated using a hashing algorithm applied to the entire selected representation data (see Section 8.1 of [HTTP]).
Representations take into account the effect of the HTTP semantics on messages. For example, the content can be affected by range requests or methods, such as HEAD, while the way the content is transferred "on the wire" is dependent on other transformations (e.g., transfer codings for HTTP/1.1; see Section 6.1 of [HTTP/1.1]). To help illustrate HTTP representation concepts, several examples are provided in Appendix A.
When a message has no representation data, it is still possible to assert that no representation data was sent by computing the digest on an empty string (see Section 6.3).
Repr-Digest is a Dictionary (see Section 3.2 of [STRUCTURED-FIELDS]), where each:
-
key conveys the hashing algorithm (see Section 5) used to compute the digest;
-
value is a Byte Sequence that conveys an encoded version of the byte output produced by the digest calculation.
For example:
NOTE: '' line wrapping per RFC 8792
Repr-Digest: \
sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
The Dictionary type can be used to attach multiple digests calculated using different hashing algorithms in order to support a population of endpoints with different or evolving capabilities. Such an approach could support transitions away from weaker algorithms (see Section 6.6).
NOTE: '' line wrapping per RFC 8792
Repr-Digest: \
sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\
sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
A recipient MAY ignore any or all digests. Application-specific behavior or local policy MAY set additional constraints on the processing and validation practices of the conveyed digests. The security considerations cover some of the issues related to ignoring digests (see Section 6.6) and validating multiple digests (see Section 6.7).
A sender MAY send a digest without knowing whether the recipient supports a given hashing algorithm. A sender MAY send a digest if it knows the recipient will ignore it.
Repr-Digest can be sent in a trailer section. In this case, Repr-Digest MAY be merged into the header section; see Section 6.5.1 of [HTTP].
3.1. Using Repr-Digest in State-Changing Requests
When the representation enclosed in a state-changing request does not describe the target resource, the representation digest MUST be computed on the representation data. This is the only possible choice because representation digest requires complete representation metadata (see Section 3).
In responses,
-
if the representation describes the status of the request, Repr-Digest MUST be computed on the enclosed representation (see Appendix B.8);
-
if there is a referenced resource, Repr-Digest MUST be computed on the selected representation of the referenced resource even if that is different from the target resource. This might or might not result in computing Repr-Digest on the enclosed representation.
The latter case is done according to the HTTP semantics of the given method, for example, using the Content-Location header field (see Section 8.7 of [HTTP]). In contrast, the Location header field does not affect Repr-Digest because it is not representation metadata.
For example, in PATCH requests, the representation digest will be computed on the patch document because the representation metadata refers to the patch document and not the target resource (see Section 2 of [PATCH]). In responses, instead, the representation digest will be computed on the selected representation of the patched resource.
3.2. Repr-Digest and Content-Location in Responses
When a state-changing method returns the Content-Location header field, the enclosed representation refers to the resource identified by its value and Repr-Digest is computed accordingly. An example is given in Appendix B.7.