Skip to main content

4. Integrity Preference Fields

Senders can indicate their interest in Integrity fields and hashing algorithm preferences using the Want-Content-Digest or Want-Repr-Digest HTTP fields. These can be used in both requests and responses.

Want-Content-Digest indicates that the sender would like to receive (via the Content-Digest field) a content digest on messages associated with the request URI and representation metadata. Want-Repr-Digest indicates that the sender would like to receive (via the Repr-Digest field) a representation digest on messages associated with the request URI and representation metadata.

If Want-Content-Digest or Want-Repr-Digest are used in a response, it indicates that the server would like the client to provide the respective Integrity field on future requests.

Integrity preference fields are only a hint. The receiver of the field can ignore it and send an Integrity field using any algorithm or omit the field entirely; for example, see Appendix C.2. It is not a protocol error if preferences are ignored. Applications that use Integrity fields and Integrity preferences can define expectations or constraints that operate in addition to this specification. Ignored preferences are an application-specific concern.

Want-Content-Digest and Want-Repr-Digest are of type Dictionary where each:

  • key conveys the hashing algorithm (see Section 5);

  • value is an Integer (Section 3.3.1 of [STRUCTURED-FIELDS]) that conveys an ascending, relative, weighted preference. It must be in the range 0 to 10 inclusive. 1 is the least preferred, 10 is the most preferred, and a value of 0 means "not acceptable".

Examples:

Want-Repr-Digest: sha-256=1
Want-Repr-Digest: sha-512=3, sha-256=10, unixsum=0
Want-Content-Digest: sha-256=1
Want-Content-Digest: sha-512=3, sha-256=10, unixsum=0
Last updated on