HTTP Headers
Repr Digest
HTTP Header
The HTTP Repr-Digest request and response header provide a digest of the specific representation of the target resource.
It can be used to verify the integrity of the entire representation after it has been received and reconstructed.
The selected representation refers to the particular format of a resource chosen through content negotiation.
Details regarding the representation can be identified from representation headers, such as Content-Language, Content-Type, and Content-Encoding.
The representation digest applies to the entire representation rather than to the encoding or chunking methods used to transmit it.
A Content-Digest pertains to the content of a specific message, and its value will vary depending on the Content-Encoding and Content-Range of each message.
Syntax
Repr-Digest: <digest-algorithm>=<digest-value>
// Multiple digest algorithms
Repr-Digest: <digest-algorithm>=<digest-value>,…,<digest-algorithmN>=<digest-valueN>
Directives
Directives
<digest-algorithm>The algorithm used to generate a digest of the representation.
Only two registered digest algorithms are considered secure:sha-512andsha-256.
The insecure (legacy) registered digest algorithms include:md5,sha(SHA-1),unixsum,unixcksum,adler(ADLER32), andcrc32c.<digest-value>The digest in bytes of the representation using the
<digest-algorithm>.
The choice of digest algorithm also determines the encoding:sha-512andsha-256use base64 encoding, while some legacy algorithms likeunixsumuse decimal integers.
Unlike earlier drafts of this specification, the standard-base64-encoded digest bytes are wrapped in colons (:) as part of the dictionary syntax.
Using insecure digest algorithms is discouraged because collisions can be artificially created, compromising the digest’s reliability.
Unless working with legacy systems (which is uncommon today since most expect the deprecated Digest header and may not understand this specification), it is advisable to omit a Repr-Digest or use a secure digest algorithm.
Example
A Digest header was introduced in earlier specifications, but it proved problematic because the scope of what the digest applied to was unclear.
Specifically, it was difficult to determine whether a digest referred to the entire resource representation or to the specific content of an HTTP message.
Therefore, two separate headers were created: Content-Digest for the HTTP message content and Repr-Digest for the resource representation, to clarify their purposes.
**Examples**
In the following example, a user-agent sends a digest of the message content using SHA-512.
Both Content-Digest and Repr-Digest are sent, and they differ due to the Content-Encoding:
In the request:
Destination: POST /bank_transfer HTTP/1.1
Host: example.com
Content-Encoding: zstd
Content-Digest: sha-512=:ABC…=:
Repr-Digest: sha-512=:DEF…=:
{
“recipient”: “Alex”,
“amount”: 900000000
}
The server can compute a digest of the received content and compare it with the Content-Digest or Repr-Digest headers to verify message integrity.
In such cases, the Repr-Digest is more useful because it is calculated over the decoded representation, making it more consistent across different scenarios.
**When Repr-Digest and Content-Digest coincide**
An HTTP server may send the entire representation unencoded in a single message.
In this situation, the Repr-Digest and Content-Digest will have identical values for the same digest algorithms:
Example:
…
Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:
Content-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:
…
Content-Type: text/yaml
Content-Encoding: br
Content-Length: 38054
Content-Range: 0-38053/38054
…
[message body]
**When Repr-Digest and Content-Digest diverge**
A server might compress the content before sending.
In this case, the Content-Digest depends on the Content-Encoding header and will differ from the Repr-Digest header.
Example:
…
Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U59TCCaZPA9Qio3CzHJVAgDnIAut53t5Sgkj2Gv4BvDd0b+OX9QpIdgWkzdXLmBsmvBrf3t5PBt+UrVK6k5dkw==:
Content-Digest: sha-256=:293wcr5IoFAsDCzdoDXR1Qppgf2yxOPO1bvQ3nZQtuI=:, unixsum=54809
…
Content-Type: text/html; charset=utf-8
Content-Encoding: zstd
…
[message body]
In another response with different compression, the Content-Digest changes, but the Repr-Digest remains the same:
Example:
…
Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U59TCCaZPA9Qio3CzHJVAgDnIAut53t5Sgkj2Gv4BvDd0b+OX9QpIdgWkzdXLmBsmvBrf3t5PBt+UrVK6k5dkw==:
Content-Digest: sha-256=:rv9Jivc4TmcacLUshzN3OdX7Hz+ORnQRaiTaIKZQ0zk=:
…
Content-Type: text/html; charset=utf-8
Content-Encoding: zstd
…
[message body]
**Successful request employing Want-Repr-Digest, Repr-Digest, and Content-Digest**
A PUT request includes a Want-Repr-Digest header, asking the server to include a Repr-Digest with a sha-256 if successful:
Request:
Destination: PUT /api/transact HTTP/1.1
Want-Repr-Digest: sha-256=8
Content-Type: text/json
…
[message body]
The server responds with a 201 Created status, including Repr-Digest and Content-Digest headers with the respective sha-256 digests:
Response:
HTTP/1.1 201 Created
Repr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:
Content-Encoding: br
Content-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=:
…
[message body]
**Unsuccessful request with Repr-Digest**
A user-agent requests a resource with a specified sha-256 digest:
Request:
Destination: GET /api/last-transaction HTTP/1.1
Accept: text/json
Repr-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=:
…
The server returns a 406 Not Acceptable response, including the Repr-Digest header with the sha-256 digest that would have resulted in success:
Response:
HTTP/1.1 406 Not Acceptable
Repr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:
…
**Browser Compatibility**
This header has no specific browser support as it isn’t defined in browser specifications.
Developers can leverage fetch() to set and retrieve HTTP headers for application-specific behaviors.
How to Modify Header using Requestly
Requestly is a powerful Chrome extension that allows you to modify HTTP headers, including the Repr-Digest header. This is especially useful for testing how your application handles different representations or verifying server responses when using specific content digests. Steps to Modify the Repr-Digest Header:
- Install and open the Requestly Chrome extension. You can find it on the Chrome Web Store.
- Create a new rule: Click on “Create Rule” and choose “Modify Headers” from the list of available rule types.
- Add a new header modification:
- Under “Action”, select “Add” or “Override”.
- In the “Header Name” field, enter Repr-Digest.
- In the “Header Value” field, enter your desired digest value (e.g., sha-256=:W6ph5Mm5Pz8GgiULbPgzG37mj9g=:).
- Set the URL condition: Specify the URL or pattern where this header change should apply (e.g., https://your-api.com/*).
- Save the rule.
Once set up, Requestly will inject the Repr-Digest header into all matching requests, allowing you to simulate different client requests or test how your server validates content digests. Modifying the Repr-Digest header can help you test how your application handles integrity or versioning of resources, ensuring data consistency and correctness during development or troubleshooting.
Table of Contents
- No headings found.
