Prompt and scope
A file-upload API must let clients verify that HTTP content was not rewritten by a gateway or cache. Based on RFC 9530, design the use of Content-Digest, Repr-Digest, and Want-Repr-Digest, and explain their boundaries with TLS, signatures, and retries.
The question tests whether you can bind a digest to the correct HTTP layer: Content-Digest covers actual message content, Repr-Digest describes the selected representation, and Want-Repr-Digest expresses a receiver’s preference for representation digests. A digest checks content integrity; by itself it does not prove who sent the message.
What the interviewer is testing
Cover the distinction between message content and representations, safe algorithm selection, request and response negotiation, proxy and compression boundaries, streaming computation, the digest-failure state machine, and the correct combination of digests with authentication, TLS, retries, and idempotency.
A 30-second answer
“I first define the object and byte boundary being verified. The upload client computes Content-Digest, and the server verifies it while streaming the received message. The server may return Repr-Digest, which the client checks against the final representation. Want-Repr-Digest communicates algorithm preferences; the server chooses only an allowed strong algorithm and records the result. A mismatch stops delivery or persistence. Sender authentication still comes from TLS, HTTP Message Signatures, or an access token.”
Step-by-step solution
Step 1: Define the protected object
State whether the goal is the transferred message content or a representation after content negotiation. Content-Digest applies to the actual message content; Repr-Digest describes the selected representation. A representation digest cannot validate a different byte sequence after transcoding.
Step 2: Select digest algorithms
Use an allowlist containing currently approved algorithms such as SHA-256 or SHA-512, and reject legacy choices such as MD5 or SHA-1. While parsing the structured field, reject duplicate algorithms, unknown parameters, and malformed encodings so different libraries cannot interpret one value differently.
Step 3: Verify requests
The upload client computes Content-Digest over the final message bytes. The server computes it while reading and compares only after the message ends. A mismatch prevents object commit and event publication; partial output is never treated as success. Large uploads should be streamed rather than buffered in memory.
Step 4: Verify responses
The server can send Repr-Digest in the response. The client computes the digest over the decoded selected representation according to the negotiated rule. If compression is involved, the protocol must state whether the digest covers the compressed message or the uncompressed representation; clients must not mix those layers.
Step 5: Use Want-Repr-Digest
A client can send Want-Repr-Digest with algorithm preferences and weights. The server may satisfy it, select another allowed algorithm, or omit the response field. The client must distinguish “digest not provided” from “digest mismatch”; absence is not successful verification.
Step 6: Handle proxies and caches
A cache hit still needs a digest matching the current representation. If a gateway recompresses, transcodes, or combines content, it must recompute the relevant digest; copying the upstream field creates a false result. Rewriting a field outside the digest’s covered bytes does not automatically break the digest, but it may change signature or authorization semantics.
Step 7: Combine authentication and replay protection
A digest proves a byte relationship, not sender identity, and it does not stop a valid message from being sent again. Use TLS, HTTP Message Signatures, or tokens for sender authentication. Use a nonce, time window, and business idempotency key to prevent duplicate charges. A digest value is not an authorization credential.
Step 8: Define failures and observability
Expose separate metrics and error classes for mismatch, disallowed algorithm, malformed field, and missing field. Clean up temporary objects after upload verification fails; discard an unverified cached response and trigger the retry policy. Log the algorithm, request ID, size, and failure class, never sensitive content or a complete payload.
Trade-offs and boundaries
Content-Digest or Repr-Digest
Content-Digest is suited to verifying what this HTTP message actually transferred. Repr-Digest is suited to caches, content negotiation, and resource-representation verification. They can coexist, but the protocol must document byte boundaries and decoding order.
Digest or digital signature
Digests are inexpensive and detect changes in transit or storage. Digital signatures additionally authenticate a key holder and support cross-system verification. A signature can cover a digest field to bind content integrity to the method and target, but the digest itself has no identity property.
Fail closed or degrade
Payments, software packages, and regulated archives should reject missing or mismatched digests. An ordinary static resource with an optional digest may continue after recording an alert, but the caller must know that integrity was not verified; it must not be silently marked trusted.
Failure drills and evolution
Gateway recompresses a response
Have a gateway change the compression, then verify that the client still hashes the protocol-defined representation layer. If the gateway changed the covered layer, it must generate a new field.
A byte changes during upload
Replace one byte in a proxy and verify that the server reports a Content-Digest mismatch before committing the object, then removes temporary data and downstream events.
Algorithm downgrade or missing field
Send a preference containing a legacy algorithm and verify that the server rejects the disallowed choice. Remove Repr-Digest and confirm that the client enters an “unverified” branch rather than a success branch.
Common mistakes and follow-ups
Mistake 1: Treating a digest as authentication
Follow-up: Can an attacker recompute the digest for their own content? Yes. TLS, a signature, or a token is still required to authenticate the sender.
Mistake 2: Ignoring compression and representation layers
Follow-up: Can an upstream digest be copied to a recompressed response? Only when the covered byte layer is unchanged; otherwise it must be recomputed.
Mistake 3: Treating a missing field as verified
Follow-up: What if the server omits a requested digest? Mark the result unverified or reject it according to policy; omission is not a match.
Deeper follow-ups and model answers
Why can an upload request use Content-Digest?
The sender can provide a digest before transmission or as a stream completes, allowing the receiver to verify the bytes before persistence. Large objects should be hashed incrementally rather than buffered.
Are digest fields replay protection?
No. The same valid message can be sent again. Replay protection needs time windows, nonces, signature coverage, and business idempotency state.
Should a proxy delete an upstream digest?
Only when it changed covered bytes and cannot recompute the field should it remove or mark it unusable. If it can recompute, it should generate a value for the final message or representation and document the boundary of responsibility.